Re: [PATCH v4 2/2] rerere: go on at a conflict when the lock stays busy
On Mon, Sep 14, 2026 at 08:04:21AM +0000, Thomas Bachem via GitGitGadget wrote:
Show 32 quoted lines
> 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