)]}'
{
  "commit": "1c72895097f290b1fdea87bb4b62fb3517e5f14f",
  "tree": "96e19e98d92cfd5b1a96c74678c48d207fc9841d",
  "parents": [
    "fc6fd56904b8ab577df8cc46a96b2d808909a4f8"
  ],
  "author": {
    "name": "Daniele Sassoli",
    "email": "danielesassoli@gmail.com",
    "time": "Mon May 12 11:56:52 2025 +0100"
  },
  "committer": {
    "name": "Daniele Sassoli",
    "email": "danielesassoli@gmail.com",
    "time": "Thu May 29 21:13:45 2025 +0000"
  },
  "message": "Use the same ordering/locking in delete() as C git\n\nFollowing the examples of cgit, lock packed-refs *before* checking for\nexistance of refs in it [1] and *keep the lock* until the loose ref (if\nany) is removed [2]. The packed-refs lock is kept even when no\npacked-refs update is required [3] so that somebody else doesn\u0027t pack a\nreference that we are trying to delete.\n\nThis fixes a concurrency issue that happens on projects with a\nsubstantial amount of refs(\u003e~500k) where packing takes long enough for a\nref deletion to be triggered half way through it. Not locking the\npacked-refs file before checking if the refs exists is not safe, as it\nopens up situations where loose refs are repacked in memory and locked\non disk, but before the lock is released and packed-refs is flushed to\ndisk, a ref is deleted.\n\nAs packed-refs was NOT locked while checking wether a ref existed in it,\nthe current content on disk was read, which was about to be overwritten\nand did not contain the ref about to be deleted. As the delete doesn\u0027t\nsee the ref in the current, on-disk, version of packed refs, it skips\nprocessing altogether and moves on, correctly, deleting only the\nassociated loose ref and leaving the packed one behind.\n\nOnce the new packed-refs, containing the ref that was just deleted, was\ncommited to disk, the ref would come back to life.\n\nTherefore, the packed-refs needs to be locked before checking if it\ncontains a ref or not in the same way the C implementation of Git does\nat [1].\n\nThere are tradeoffs, though, in this decision, which will reduce the\nparallelism of deleting loose refs and performing the refs repacking,\nwhich happens very often in certain JGit implementations like Gerrit\nCode Review. Before this change, repacking of refs and removal of loose\nrefs unrelated to the in-flight repacking was possible without involving\nany locking; after this change, all loose refs removals have to wait for\nthe packing of refs to be completed, even though the repacking and the\nrefs removals were completely unrelated and their namespaces disjoint.\nSee more details on the test\u0027s performance results and the associated\ntradeoffs in the Issue jgit-152.\n\nNOTE: This delete ref locking logic was incorrect regardless of how the\npacking of the refs is implemented. Making decisions if the pack\ntransaction is needed or not on an unlocked resource is racy and also\nflagged as bug at [1].\n\n[1]https://github.com/git/git/blob/master/refs/packed-backend.c#L1590\n[2]https://github.com/git/git/blob/master/refs/files-backend.c#L3261\n[3]https://github.com/git/git/blob/master/refs/files-backend.c#L2943\n\nBug: jgit-152\nChange-Id: I158ec837904617c5fdf667e295ae667b2f037945\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "8e57bf9f2fcf887248e8c411a1913d2403fa033c",
      "old_mode": 33188,
      "old_path": "org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/RefDirectory.java",
      "new_id": "321584b56b60f0bf382bf6316f5ccc1cf7fb1b56",
      "new_mode": 33188,
      "new_path": "org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/file/RefDirectory.java"
    }
  ]
}