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

Hi Junio,

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

quoted

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