From: Patrick Steinhardt Date: Mon, 07 Sep 2026 06:15:21 GMT Subject: Re: [PATCH v2 0/2] builtin/maintenance: improve heuristic for "rerere gc" Message-ID: In-Reply-To: On Fri, Sep 04, 2026 at 06:53:59PM +0200, Thomas Bachem wrote: > 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 > > > 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. Yes, exactly. This is really two issues: - rerere cannot handle concurrent writes at all, and will die immediately when somebody else has taken the lock. This is a long-standing issue, and should be fixed via Thomas' series that introduces a timeout for the lock. - The heuristic for garbage collecting rerere entries is way too trigger-friendly, which wastes resources and makes the above issue more likely to trigger. So in the end, we want to have both patch series merged to address the issue from both ends. Thanks! Patrick