)]}'
{
  "commit": "6aff1f25a046f3dcd8a78b0c61414fa2d1c9a93c",
  "tree": "92d040dec92994c124b39e38040b43365778b52e",
  "parents": [
    "589127caa73090040200989ff4d24c3d54f473f2"
  ],
  "author": {
    "name": "Patrick Steinhardt",
    "email": "ps@pks.im",
    "time": "Thu Oct 30 11:38:44 2025 +0100"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Thu Oct 30 07:09:53 2025 -0700"
  },
  "message": "packfile: always add packfiles to MRU when adding a pack\n\nWhen preparing the packfile store we know to also prepare the MRU list\nof packfiles with all packs that are currently loaded in the store via\n`packfile_store_prepare_mru()`. So we know that the list of packs in the\nMRU list should match the list of packs in the non-MRU list.\n\nBut there are some direct or indirect callsites that add a packfile to\nthe store via `packfile_store_add_pack()` without adding the pack to the\nMRU. And while functions that access the MRU (e.g. `find_pack_entry()`)\nknow to call `packfile_store_prepare()`, which knows to prepare the MRU\nvia `packfile_store_prepare_mru()`, that operation will be turned into a\nno-op because the packfile store is already prepared. So this will not\ncause us to add the packfile to the MRU, and consequently we won\u0027t be\nable to find the packfile in our MRU list.\n\nThere are only a handful of callers outside of \"packfile.c\" that add a\npackfile to the store:\n\n  - \"builtin/fast-import.c\" adds multiple packs of imported objects, but\n    it knows to look up objects via `packfile_store_get_packs()`. This\n    function does not use the MRU, so we\u0027re good.\n\n  - \"builtin/index-pack.c\" adds the indexed pack to the store in case it\n    needs to perform consistency checks on its objects.\n\n  - \"http.c\" adds the fetched pack to the store so that we can access\n    its objects.\n\nIn all of these cases we actually want to access the contained objects.\nAnd luckily, reading these objects works as expected:\n\n  1. We eventually end up in `do_oid_object_info_extended()`.\n\n  2. Calling `find_pack_entry()` fails because the MRU list doesn\u0027t\n     contain the newly added packfile.\n\n  3. The callers don\u0027t pass `OBJECT_INFO_QUICK`, so we end up\n     repreparing the object database. This will also cause us to\n     reprepare the MRU list.\n\n  4. We now retry reading the object via `find_pack_entry()`, and now we\n     succeed because the MRU list got populated.\n\nThis logic feels quite fragile: we intentionally add the packfile to the\nstore, but we then ultimately rely on repreparing the entire store only\nto make the packfile accessible. While we do the correct thing in\n`do_oid_object_info_extended()`, other sites that access the MRU may not\nknow to reprepare.\n\nBut besides being fragile it\u0027s also a waste of resources: repreparing\nthe object database requires us to re-read the alternates file and\ndiscard any caches.\n\nRefactor the code so that we unconditionally add packfiles to the MRU\nwhen adding them to a packfile store. This makes the logic less fragile\nand ensures that we don\u0027t have to reprepare the store to make the pack\naccessible.\n\nNote that this does not allow us to drop `packfile_store_prepare_mru()`\njust yet: while the MRU list is already populated with all packs now,\nthe order in which we add these packs is indeterministic for most of the\npart. So by first calling `sort_pack()` on the other packfile list and\nthen re-preparing the MRU list we inherit its sorting.\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": "8022be9a45ecb981a54d9e0ed573d0b3d020d4a8",
      "old_mode": 33188,
      "old_path": "midx.c",
      "new_id": "24e1e721754d0cbffed53d7545f12bca77d157bd",
      "new_mode": 33188,
      "new_path": "midx.c"
    },
    {
      "type": "modify",
      "old_id": "71e95ae11c56d225b3ccb1763d9c3cc3b1ba5a3a",
      "old_mode": 33188,
      "old_path": "packfile.c",
      "new_id": "60f2e42876a82372ff2f17afd5f1214c04018d80",
      "new_mode": 33188,
      "new_path": "packfile.c"
    }
  ]
}