)]}'
{
  "commit": "c31bad4f7dcf3e04ae22e7d4a1059fd628acf1a2",
  "tree": "e834be384525f7b9546a71453d7b6a862e652a8f",
  "parents": [
    "6aff1f25a046f3dcd8a78b0c61414fa2d1c9a93c"
  ],
  "author": {
    "name": "Patrick Steinhardt",
    "email": "ps@pks.im",
    "time": "Thu Oct 30 11:38:45 2025 +0100"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Thu Oct 30 07:09:53 2025 -0700"
  },
  "message": "packfile: track packs via the MRU list exclusively\n\nWe track packfiles via two different lists:\n\n  - `struct packfile_store::packs` is a list that sorts local packs\n    first. In addition, these packs are sorted so that younger packs are\n    sorted towards the front.\n\n  - `struct packfile_store::mru` is a list that sorts packs so that\n    most-recently used packs are at the front.\n\nThe reasoning behind the ordering in the `packs` list is that younger\nobjects stored in the local object store tend to be accessed more\nfrequently, and that is certainly true for some cases. But there are\ngoing to be lots of cases where that isn\u0027t true. Especially when\ntraversing history it is likely that one needs to access many older\nobjects, and due to our housekeeping it is very likely that almost all\nof those older objects will be contained in one large pack that is\noldest.\n\nSo whether or not the ordering makes sense really depends on the use\ncase at hand. A flexible approach like our MRU list addresses that need,\nas it will sort packs towards the front that are accessed all the time.\nIntuitively, this approach is thus able to satisfy more use cases more\nefficiently.\n\nThis reasoning casts some doubt on whether or not it really makes sense\nto track packs via two different lists. It causes confusion, and it is\nnot clear whether there are use cases where the `packs` list really is\nsuch an obvious choice.\n\nMerge these two lists into one most-recently-used list.\n\nNote that there is one important edge case: `for_each_packed_object()`\nuses the MRU list to iterate through packs, and then it lists each\nobject in those packs. This would have the effect that we now sort the\ncurrent pack towards the front, thus modifying the list of packfiles we\nare iterating over, with the consequence that we\u0027ll see an infinite\nloop. This edge case is worked around by introducing a new field that\nallows us to skip updating the MRU.\n\nSigned-off-by: Patrick Steinhardt \u003cps@pks.im\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b83eb8ead14139516a183fc0503189aa3a6c90be",
      "old_mode": 33188,
      "old_path": "builtin/pack-objects.c",
      "new_id": "0e4e9f80682fd654d64e568b26d17b871e9a9390",
      "new_mode": 33188,
      "new_path": "builtin/pack-objects.c"
    },
    {
      "type": "modify",
      "old_id": "60f2e42876a82372ff2f17afd5f1214c04018d80",
      "old_mode": 33188,
      "old_path": "packfile.c",
      "new_id": "378b0b1920d4937c335398cb565a7308692452c8",
      "new_mode": 33188,
      "new_path": "packfile.c"
    },
    {
      "type": "modify",
      "old_id": "d95275e666c95eb5ee993c176951178a80b8c5d6",
      "old_mode": 33188,
      "old_path": "packfile.h",
      "new_id": "27ba607e7c5eae20fe86ab4fd672705605f879c4",
      "new_mode": 33188,
      "new_path": "packfile.h"
    }
  ]
}