From: Patrick Steinhardt <ps@pks.im>
Date: Mon, 28 Sep 2026 08:18:18 GMT
Subject: Re: [PATCH v4 2/2] rerere: go on at a conflict when the lock stays busy
Message-ID: <aroiyibdbr7PKqST@pks.im>
In-Reply-To: <1cce403113833c14a1c4a0da0db0772c5abdeb1c.1789373061.git.gitgitgadget@gmail.com>

On Mon, Sep 14, 2026 at 08:04:21AM +0000, Thomas Bachem via GitGitGadget wrote:
> diff --git a/rerere.c b/rerere.c
> index 7d44f3937c..a996d39159 100644
> --- a/rerere.c
> +++ b/rerere.c
> @@ -900,18 +902,26 @@ int setup_rerere(struct repository *r, struct string_list *merge_rr, int flags)
>  		 * Another process may hold the lock for a while, e.g.
>  		 * "git rerere gc" while it prunes rr-cache, so wait for
>  		 * it instead of dying right away.  The gc itself never
> -		 * waits: skipping one of its runs costs nothing.
> +		 * waits: skipping one of its runs costs nothing.  A
> +		 * command that stops at a conflict must not die here
> +		 * either, so it warns and goes on without rerere.
>  		 */
>  		if (flags & RERERE_NOWAIT) {
>  			lock_flags = 0;
>  			timeout_ms = 0;
>  		}
> +		if (flags & RERERE_SKIP_LOCKED)
> +			lock_flags = 0;
>  		fd = repo_hold_lock_file_for_update_timeout(r, &write_lock,
>  							    path, lock_flags,
>  							    timeout_ms);
>  		if (fd < 0) {
>  			warning_errno(_("skipping rerere, "
>  					"unable to create '%s.lock'"), path);
> +			if (flags & RERERE_SKIP_LOCKED)
> +				advise(_("run \"git rerere\" before resolving "
> +					 "the conflict to record or replay "
> +					 "its resolution"));
>  			return -1;
>  		}
>  	}

Should this use `advise_if_enabled()`?

Patrick