Hi Junio,
On 04/09/2026 18:14, Junio C Hamano wrote:
So the two-patch series is not about what happens when two "rerere
gc" trigger in quick successions, and even with the "improve"d
heuristic, the second "rerere gc" would fail the same way when when
another one is already running?
Right, Patrick's series only makes the gc run less often. The lock
itself is the subject of
[PATCH v3] rerere: keep a background gc from killing a rebase
[ref]
where setup_rerere() waits rerere.lockTimeout for it and then goes on
without rerere, and a gc that finds it held gives up at once.
Thomas