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

From: Thomas Bachem <mail@thomasbachem.com>
Date: Sep 6, 2026, 10:29 UTC
Message-ID: <CAA0xjtoFD3OQqPhf82hxkUZ4-zpSH28arz6aBxSqeMeR1BqBhQ@mail.gmail.com>
In-Reply-To: <xmqqwlsz65mu.fsf@gitster.g>

Hi Junio,

On 05/09/2026 18:10, Junio C Hamano wrote:

> Would it make sense to LOUDLY tell the user when "git rerere" fails
> to do what the user expects to do?

It would, and the user gets everything back. At the stop the conflict is still in the index, so "git rerere" run by hand right there records the preimage that was skipped, "git rebase --continue" then records the resolution, and replaying the same conflict resolves it from the cache. A resolution it would have replayed comes back the same way, so one command covers whatever was skipped. I checked all of it.

Your "BEFORE DOING ANYTHING ELSE" has to be in there, though. Resolve the file first and the conflict markers go with it, and "git rerere" records nothing at all.

Failing doesn't record anything either, and the conflict is still sitting there to record by hand afterwards, so what it buys over a warning is that the user can't miss it. I agreed to that trade without checking what it costs.

Show 6 quoted lines

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

It's rougher than that. The "you have staged changes" refusal from the log message offers "git commit --amend" or "git commit", and neither gets commit #70 back as it was. The first folds its changes into #69 and drops its message, and the rebase then runs to the end, one commit short. The second keeps the message but not the author. Aborting does work, but the user first has to ignore what git just told them to do.

That's 2.55 today, not something this patch adds, and waiting only makes it rarer. Writing the stop state before rerere runs would let the rebase continue, but the recording is still gone, so the message is needed there too.

I'd rather not stop a rebase the user can otherwise finish over a recording we can tell them how to get back, so I'd keep v3's behavior at a conflict, where the command stops anyway and the warning can say to run "git rerere" before resolving. The recording after the resolution is different: "git am --continue" and a rebase's "git commit" go on with the rest, and a leftover MERGE_RR entry then records whatever the file holds at the next rerere run, as with the clears. So those keep failing after the wait. "git rerere", "forget" and "clear" fail after it too, so do the clears that "am" and "rebase" run, and the gc gives up at once. Say if you'd still rather all of it failed and I'll build that instead.

Thanks, Thomas