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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> 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.

Hmph.

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?