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

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

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