Re: [PATCH v3] rerere: keep a background gc from killing a rebase

From: Thomas Bachem <mail@thomasbachem.com>
Date: Sep 5, 2026, 05:41 UTC
Message-ID: <CAA0xjtqF_60kKC_B=-=AkBSG0ZiFd_uSjzCZ4Bup8Pvg1_uALQ@mail.gmail.com>
In-Reply-To: <xmqq4ig44ywy.fsf@gitster.g>

Hi Junio,

On 04/09/2026 21:08, Junio C Hamano wrote:

Show 7 quoted lines

>> semantics of core.packedRefsTimeout, then warn and go on without
>> rerere: a lost recording or replay is nothing next to a rebase that
>> cannot continue.
>
> Perhaps it is just the way the above three lines is stated and what
> the code actually does may not be problematic, but I am not sure if
> that is what the latter half of the above sentence is trying to say.

No, it's what the code does. Once the timeout is up, the conflicted step goes on without recording the preimage, and the resolution the user makes after that is lost, as you say.

The rebase that cannot continue is the one from the message's first paragraph. It dies inside rerere, which do_pick_commit() runs before error_with_patch() writes the state "git rebase --continue" needs, so I traded the recording for a rebase that survives. You've convinced me that's the wrong trade.

So in v4 every caller waits rerere.lockTimeout and then fails as it does today, and only "git rerere gc" gives up at once. That drops the RERERE_LOCK_OR_DIE flag and the hunks in the callers, and it takes back what I said in my reply to your other mail about merge and commit going on without rerere.

A gc that outlasts the timeout still stops the rebase where it does today. With the gc giving way whenever it comes second and the sequencer series keeping a rebase's own commits from starting one, that should be rare. Whoever would rather wait it out can set rerere.lockTimeout to -1, but I'd keep the default finite so a lock left behind by a crash fails like every other lock instead of hanging. Writing the stop state before rerere runs would let such a rebase continue, which I can look at separately.

Thanks, Thomas