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

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

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.

> Changes in v2:
>   - Restore `prune_one()`.
>   - Handle "maintenance.rerere-gc.auto" values explicitly.
>   - Rename `rerere_gc_estimate()` to `rerere_gc_needed()`.
>   - Link to v1: https://patch.msgid.link/20260903-b4-pks-maintenance-rerere-gc-heuristic-v1-0-9929c45a9788@pks.im

I find that all the changes between v1 and v2 that came as response
to Derrick's review highly valuable.  The "cute" expression is gone
and the result is much easier to read ;-).

Thanks.