)]}'
{
  "commit": "b739d971e5f9997d90bc09b6c8cfdc677e3a0da6",
  "tree": "4798071a3eddc33caec82a3b6babbc1e8449322a",
  "parents": [
    "30e9940356dc67959877f4b2417da33ebdefbb79"
  ],
  "author": {
    "name": "Derrick Stolee",
    "email": "dstolee@microsoft.com",
    "time": "Fri Mar 13 21:11:55 2020 +0000"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Sun Mar 15 15:39:00 2020 -0700"
  },
  "message": "connected.c: reprepare packs for corner cases\n\nWhile updating the microsoft/git fork on top of v2.26.0-rc0 and\nconsuming that build into Scalar, I noticed a corner case bug around\npartial clone.\n\nThe \"scalar clone\" command can create a Git repository with the\nproper config for using partial clone with the \"blob:none\" filter.\nInstead of calling \"git clone\", it runs \"git init\" then sets a few\nmore config values before running \"git fetch\".\n\nIn our builds on v2.26.0-rc0, we noticed that our \"git fetch\"\ncommand was failing with\n\n  error: https://github.com/microsoft/scalar did not send all necessary objects\n\nThis does not happen if you copy the config file from a repository\ncreated by \"git clone --filter\u003dblob:none \u003curl\u003e\", but it does happen\nwhen adding the config option \"core.logAllRefUpdates \u003d true\".\n\nBy debugging, I was able to see that the loop inside\ncheck_connnected() that checks if all refs are contained in\npromisor packs actually did not have any packfiles in the packed_git\nlist.\n\nI\u0027m not sure what corner-case issues caused this config option to\nprevent the reprepare_packed_git() from being called at the proper\nspot during the fetch operation. This approach requires a situation\nwhere we use the remote helper process, which makes it difficult to\ntest.\n\nIt is possible to place a reprepare_packed_git() call in the fetch code\ncloser to where we receive a pack, but that leaves an opening for a\nlater change to re-introduce this problem. Further, a concurrent repack\noperation could replace the pack-file list we already loaded into\nmemory, causing this issue in an even harder to reproduce scenario.\n\nIt is really the responsibility of anyone looping through the list of\npack-files for a certain object to fall back to reprepare_packed_git()\non a fail-to-find. The loop in check_connected() does not have this\nfallback, leading to this bug.\n\nWe _could_ try looping through the packs and only reprepare the packs\nafter a miss, but that change is more involved and has little value.\nSince this case is isolated to the case when\nopt-\u003echeck_refs_are_promisor_objects_only is true, we are confident that\nwe are verifying the refs after downloading new data. This implies that\ncalling reprepare_packed_git() in advance is not a huge cost compared to\nthe rest of the operations already made.\n\nHelped-by: Jeff King \u003cpeff@peff.net\u003e\nHelped-by: Junio Hamano \u003cgitster@pobox.com\u003e\nSigned-off-by: Derrick Stolee \u003cdstolee@microsoft.com\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7e9bd1bc622eefa3dad76c8e786767a0ffa3077f",
      "old_mode": 33188,
      "old_path": "connected.c",
      "new_id": "ac52b07b474d6cd7700bd0f394ecbe1345fb018e",
      "new_mode": 33188,
      "new_path": "connected.c"
    }
  ]
}