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

[Patrick Steinhardt <ps@pks.im>]

On Fri, Sep 04, 2026 at 03:51:21PM +0000, Thomas Bachem via GitGitGadget wrote:
> From: Thomas Bachem <mail@thomasbachem.com>
> 
> A "git rerere gc" holds MERGE_RR.lock for as long as pruning rr-cache
> takes, and since 2.54 the auto maintenance after every commit runs
> one whenever rr-cache has an entry. The commit a rebase spawns for a
> resolved pick starts it too, and the sequencer's repo_rerere() at the
> next conflict wants the lock a few milliseconds later. Both take it
> with LOCK_DIE_ON_ERROR, so whichever comes second dies. When it is
> the rebase, the index is written but the state for "git rebase
> --continue" is not, and every later continue refuses with "you have
> staged changes".

Haven't we said that this race is not exclusive to `git rerere gc` with
a concurrent writer though? It also happens between two normal writers.
So it's good to have the context that we discovered this race because of
the changed heuristics in maintenance, but we should clarify that it's a
longer-standing conceptual issue.

> diff --git a/Documentation/config/rerere.adoc b/Documentation/config/rerere.adoc
> index 3a78b5ebb1..14ef193545 100644
> --- a/Documentation/config/rerere.adoc
> +++ b/Documentation/config/rerere.adoc
> @@ -10,3 +10,13 @@ rerere.enabled::
>  	enabled if there is an `rr-cache` directory under the
>  	`$GIT_DIR`, e.g. if "rerere" was previously used in the
>  	repository.
> +
> +rerere.lockTimeout::
> +	The length of time, in milliseconds, to retry when trying to
> +	take the rerere lock while another process holds it, typically
> +	a background `git rerere gc`.  When the time is up, the command
> +	warns and goes on without rerere.  Value 0 means not to retry
> +	at all; -1 means to try indefinitely.  Default is 1000 (i.e.,
> +	retry for 1 second).  `git rerere gc` does not retry at all.
> +	`git rerere`, `git rerere forget` and `git rerere clear` retry
> +	the same way, but fail when the time is up instead of going on.

I'm not a 100% sold that it's sensible to just skip writing the rerere
entry. But maybe it's more sensible to regress gracefully compared to
just aborting the whole command?

In any case, I feel like this change warrants its own preparatory commit
so that we can discuss separately why it's a good idea to ignore those
failures.

Patrick