)]}'
{
  "commit": "1190a1acf800acdcfd7569f87ac1560e2d077414",
  "tree": "6870ff8f5238d694fa70ebf3f9b6b54993dc0c54",
  "parents": [
    "e74435a5169b56be901196ad172b4dbda124254d"
  ],
  "author": {
    "name": "Jeff King",
    "email": "peff@peff.net",
    "time": "Thu Dec 05 15:28:07 2013 -0500"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Thu Dec 05 15:40:11 2013 -0800"
  },
  "message": "pack-objects: name pack files after trailer hash\n\nOur current scheme for naming packfiles is to calculate the\nsha1 hash of the sorted list of objects contained in the\npackfile. This gives us a unique name, so we are reasonably\nsure that two packs with the same name will contain the same\nobjects.\n\nIt does not, however, tell us that two such packs have the\nexact same bytes. This makes things awkward if we repack the\nsame set of objects. Due to run-to-run variations, the bytes\nmay not be identical (e.g., changed zlib or git versions,\ndifferent source object reuse due to new packs in the\nrepository, or even different deltas due to races during a\nmulti-threaded delta search).\n\nIn theory, this could be helpful to a program that cares\nthat the packfile contains a certain set of objects, but\ndoes not care about the particular representation. In\npractice, no part of git makes use of that, and in many\ncases it is potentially harmful. For example, if a dumb http\nclient fetches the .idx file, it must be sure to get the\nexact .pack that matches it. Similarly, a partial transfer\nof a .pack file cannot be safely resumed, as the actual\nbytes may have changed.  This could also affect a local\nclient which opened the .idx and .pack files, closes the\n.pack file (due to memory or file descriptor limits), and\nthen re-opens a changed packfile.\n\nIn all of these cases, git can detect the problem, as we\nhave the sha1 of the bytes themselves in the pack trailer\n(which we verify on transfer), and the .idx file references\nthe trailer from the matching packfile. But it would be\nsimpler and more efficient to actually get the correct\nbytes, rather than noticing the problem and having to\nrestart the operation.\n\nThis patch simply uses the pack trailer sha1 as the pack\nname. It should be similarly unique, but covers the exact\nrepresentation of the objects. Other parts of git should not\ncare, as the pack name is returned by pack-objects and is\nessentially opaque.\n\nOne test needs to be updated, because it actually corrupts a\npack and expects that re-packing the corrupted bytes will\nuse the same name. It won\u0027t anymore, but we can easily just\nuse the name that pack-objects hands back.\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": "ca9e63be18f9333bf0f603ddb9ddd923588be0aa",
      "old_mode": 33188,
      "old_path": "pack-write.c",
      "new_id": "ddc174e1adb9e1545b2815d8a1990e43f6fa2bfb",
      "new_mode": 33188,
      "new_path": "pack-write.c"
    },
    {
      "type": "modify",
      "old_id": "aa6ee7d606f1d5336bff9a3067b44057c362e788",
      "old_mode": 33188,
      "old_path": "pack.h",
      "new_id": "12d951659c16462cf2da6a43e2c4974b85e39712",
      "new_mode": 33188,
      "new_path": "pack.h"
    },
    {
      "type": "modify",
      "old_id": "fe82025d4a0dbae0cee3d0c3943617ede5b5c7a5",
      "old_mode": 33261,
      "old_path": "t/t5302-pack-index.sh",
      "new_id": "4bbb718751738c3e913c25160d0fff52d8350bba",
      "new_mode": 33261,
      "new_path": "t/t5302-pack-index.sh"
    }
  ]
}