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

Junio C Hamano [off-list ref] writes:

Patrick Steinhardt [off-list ref] writes:

quoted

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?