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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 5, 2026, 16:10 UTC
Message-ID: <xmqqwlsz65mu.fsf@gitster.g>
In-Reply-To: <CAA0xjtqF_60kKC_B=-=AkBSG0ZiFd_uSjzCZ4Bup8Pvg1_uALQ@mail.gmail.com>

Thomas Bachem <mail@thomasbachem.com> writes:

Show 7 quoted lines

>> 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.

It is a hard-to-accept regression without a good justification, though, especially with the other efforts to tame "rerere gc" from hogging the lock too often going on.

If you have a 100-commit "rebase" that is interrupted in the middle, say at commit #70, at worst you should be able to hard reset and abort it, and then restart it starting on top of the result of applying up to commit #69 (with "rebase --onto") to finish the rest, so failing in the middle is not like throwing the effort you made so far away.

Show 8 quoted lines

> 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.

Stepping back a bit, what does a "conflicted step goes on without recording the preimage" exactly look like? "git rebase" goes on chugging, and hits a commit that does not cleanly apply. It leaves a conflict and in a normal case immediately before returning the control back to the user, its "git rerere" invocation creates a preimage. Even if we make "git rerere" fail to do so, it would not be unrecoverable. The end user has control at that point, and it is not like the rest of rebase goes on without giving a chance to the user to intervene and recover.

Would it make sense to LOUDLY tell the user when "git rerere" fails to do what the user expects to do? The output at the point of time on the terminal would end with something like

    CONFLICT (content): Merge conflict in t/t0123-frotz.sh
    Auto-merging nitfol.c
    error: could not apply 8c7b68a8bf... nitfol: remove frotz
    Recorded preimage for 't/t0123-frotz.sh'
    Could not apply 8c7b68a8bf... # nitfol: remove frotz

if "git rerere" kicked in correctly, so if we said

    CONFLICT (content): Merge conflict in t/t0123-frotz.sh
    Auto-merging nitfol.c
    error: could not apply 8c7b68a8bf... nitfol: remove frotz
    FAILED TO RECORD PREIMAGE FOR 't/t0123-frotz.sh'
    Could not apply 8c7b68a8bf... # nitfol: remove frotz

    *** RUN "git rerere" MANUALLY BEFORE DOING ANYTHING ELSE ***
    *** IF YOU DO NOT WANT TO MAKE YOUR EFFORT IN RESOLVING ***
    *** THIS CONFLICT WASTED ***

or something similar, would that help the user?

I do not expect the "silent failure" to run "rerere" would not be followed by automated applications of many subsequent commits that makes it too late when the user notices what happened. An attempt to invoke "rerere" will always be followed by a stopped automation and the user will have the control at that point. So in that sense, as long as the user is told clearly that some step that usually happens and the user has learned to rely on did *not* happen, and also told how to recover from the failure, it is not too bad.

Thanks.