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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 4, 2026, 19:08 UTC
Message-ID: <xmqq4ig44ywy.fsf@gitster.g>
In-Reply-To: <pull.2214.v3.git.1788537081930.gitgitgadget@gmail.com>

"Thomas Bachem via GitGitGadget" <gitgitgadget@gmail.com> writes:

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

I do not understand the logic at the latter half of the above sentence. During a rebase, any and all opportunity to reuse a conflict resolution you made earlier is preferrable.

I would be fine if "we cannot grab the lock so let's skip without doing 'rerere gc' at all". But if a conflicted step in rebase that stops and leaves conflicts in the working tree fails to record the preimage of a conflicted path, and makes the user realize that was what happened only after the user spends significant amount of work to resolve the conflicts and the resolution is not added to the rerere database, that is a huge loss.

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.

Thanks.