Re: [PATCH v2 0/2] builtin/maintenance: improve heuristic for "rerere gc"

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 7, 2026, 06:15 UTC
Message-ID: <ap5WeY7o2dmAIn2B@pks.im>
In-Reply-To: <CAA0xjtrL8DJp61jp7s0L6L+RviwQz=-PEo7qZvCTh+8nT2cdfw@mail.gmail.com>

On Fri, Sep 04, 2026 at 06:53:59PM +0200, Thomas Bachem wrote:

Show 16 quoted lines

> 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
>   <pull.2214.v3.git.1788537081930.gitgitgadget@gmail.com>
> 
> 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