From: Patrick Steinhardt <ps@pks.im>
Date: Mon, 07 Sep 2026 06:15:36 GMT
Subject: Re: [PATCH v2 0/2] builtin/maintenance: improve heuristic for "rerere gc"
Message-ID: <ap5WiLQDzqdSyzvI@pks.im>
In-Reply-To: <xmqqfqzp6pir.fsf@gitster.g>

On Fri, Sep 04, 2026 at 07:48:44AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Hi,
> >
> > as reported and discussed in [1]. Thanks!
> 
> Can you, and everybody else, refrain from forcing all readers to
> visit a different message to understand what it is?  It does not
> help that [1] is a full description of both problem and solution
> that is not designed to be a summary to begin with, and to add
> insult to injury, it is AI slop wall of text that mistakenly thinks
> that more is better.
> 
> Perhaps you could have distilled the essense down to several lines?
> 
>     Since Git 2.54, background maintenance triggers after a commit
>     runs "git rerere gc", which acquires the MERGE_RR.lock.  During
>     rebase, a subsequent sequencer commit also tries to acquire this
>     lock within milliseconds.  Due to use of LOCK_DIE_ON_ERROR,
>     whichever arrives second aborts, causing rebase failures.
> 
> I'll leave it as an exercise to readers to summarize the solution
> part that this series (not the original one) proposes to make.

Fair, will adapt going forward.

Patrick