)]}'
{
  "commit": "20b20a22f8f7c1420e259c97ef790cb93091f475",
  "tree": "9b4262a0b8bf6de105f5f24773406c511712d686",
  "parents": [
    "58461bdf15a66f428f5ca6042cafbcc64c82c64d"
  ],
  "author": {
    "name": "Jeff King",
    "email": "peff@peff.net",
    "time": "Wed May 18 18:45:37 2016 -0400"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Thu Jun 02 15:22:24 2016 -0700"
  },
  "message": "upload-pack: provide a hook for running pack-objects\n\nWhen upload-pack serves a client request, it turns to\npack-objects to do the heavy lifting of creating a\npackfile. There\u0027s no easy way to intercept the call to\npack-objects, but there are a few good reasons to want to do\nso:\n\n  1. If you\u0027re debugging a client or server issue with\n     fetching, you may want to store a copy of the generated\n     packfile.\n\n  2. If you\u0027re gathering data from real-world fetches for\n     performance analysis or debugging, storing a copy of\n     the arguments and stdin lets you replay the pack\n     generation at your leisure.\n\n  3. You may want to insert a caching layer around\n     pack-objects; it is the most CPU- and memory-intensive\n     part of serving a fetch, and its output is a pure\n     function[1] of its input, making it an ideal place to\n     consolidate identical requests.\n\nThis patch adds a simple \"hook\" interface to intercept calls\nto pack-objects. The new test demonstrates how it can be\nused for debugging (using it for caching is a\nstraightforward extension; the tricky part is writing the\nactual caching layer).\n\nThis hook is unlike the normal hook scripts found in the\n\"hooks/\" directory of a repository. Because we promise that\nupload-pack is safe to run in an untrusted repository, we\ncannot execute arbitrary code or commands found in the\nrepository (neither in hooks/, nor in the config). So\ninstead, this hook is triggered from a config variable that\nis explicitly ignored in the per-repo config.\n\nThe config variable holds the actual shell command to run as\nthe hook.  Another approach would be to simply treat it as a\nboolean: \"should I respect the upload-pack hooks in this\nrepo?\", and then run the script from \"hooks/\" as we usually\ndo. However, that isn\u0027t as flexible; there\u0027s no way to run a\nhook approved by the site administrator (e.g., in\n\"/etc/gitconfig\") on a repository whose contents are not\ntrusted. The approach taken by this patch is more\nfine-grained, if a little less conventional for git hooks\n(it does behave similar to other configured commands like\ndiff.external, etc).\n\n[1] Pack-objects isn\u0027t _actually_ a pure function. Its\n    output depends on the exact packing of the object\n    database, and if multi-threading is used for delta\n    compression, can even differ racily. But for the\n    purposes of caching, that\u0027s OK; of the many possible\n    outputs for a given input, it is sufficient only that we\n    output one of them.\n\nSigned-off-by: Jeff King \u003cpeff@peff.net\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "53f00dbc267db194c7c5558a008fd9d8ec20068c",
      "old_mode": 33188,
      "old_path": "Documentation/config.txt",
      "new_id": "a7abcbeff3672f888b6ff6f7265cdb852502c32b",
      "new_mode": 33188,
      "new_path": "Documentation/config.txt"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "4357af15256647588b4c7d8a515eddd45835e7c7",
      "new_mode": 33261,
      "new_path": "t/t5544-pack-objects-hook.sh"
    },
    {
      "type": "modify",
      "old_id": "f19444df7bc9c19da4d2f3bf831525f7a5d6034d",
      "old_mode": 33188,
      "old_path": "upload-pack.c",
      "new_id": "8979be6394fc5a737ec83d770ac5efb63db438b4",
      "new_mode": 33188,
      "new_path": "upload-pack.c"
    }
  ]
}