Re: [PATCH v8 0/2] rerere: wait for MERGE_RR.lock, but not in auto maintenance

[Patrick Steinhardt <ps@pks.im>]

On Tue, Oct 13, 2026 at 09:20:04AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > On Tue, Oct 13, 2026 at 12:07:51PM +0000, Thomas Bachem via GitGitGadget wrote:
> >> Changes since v7:
> >> 
> >>  * The rerere.lockTimeout entry no longer says that the command fails when
> >>    the time is up (Junio).
> >> 
> >>  * The lock tests grep for the "Unable to create" message about
> >>    MERGE_RR.lock (Junio).
> >> 
> >>  * The wait for the background unlocker is now in test_when_finished
> >>    (Junio).
> >> 
> >>  * The rebase --abort test aborts its rebase in test_when_finished, so a
> >>    failed check cannot break later tests.
> >> 
> >>  * The test "merge fails once rerere.lockTimeout is up" never waits, so it
> >>    is now called "merge fails on a lock it cannot take".
> >> 
> >>  * In patch 2, rerere_gc() takes RERERE_NOWAIT again instead of its own enum
> >>    rerere_gc_flags (Patrick).
> >> 
> >>  * The comment about waiting in setup_rerere() now says "by default", and as
> >>    in patch 1 it sits directly above the call that takes the lock.
> >> 
> >>  * A comment in t7900 says why the tests with a held lock create rr-cache.
> >
> > I think this is in a good enough state by now. Thanks!
> 
> OK, thanks for writing and reviewing.  Shall we mark the topic ready
> for 'next' now?

Yeah, let's. Thanks!

Patrick