From: Thomas Bachem Date: Thu, 01 Oct 2026 08:08:16 GMT Subject: Re: [PATCH v5 2/3] rerere: add "gc --auto" that skips a held lock Message-ID: In-Reply-To: Hi Patrick, On 30/09/2026 17:00, Patrick Steinhardt wrote: > It's a bit weird to have git-rerere(1) document who calls it. We may > want to document why specifically this is useful though. I'll take that out of git-rerere(1) again. I'd keep the last sentence of the rerere.lockTimeout entry, since that is where I say what each command does when the time is up, but name the two commands there instead of the option: "A `git rerere gc` run by `git maintenance run --auto` or `git gc --auto` does not wait and does nothing while the lock is held." > How about we instead call this "--skip-locked"? We could even mark it as > a hidden option and not even document it, as it feels very specific to > how git-maintenance(1) wants to invoke it. If so, we could maybe remove > it again at a later point. I'll take both, the name and hiding it. Patch 3 has a RERERE_SKIP_LOCKED flag for the conflict-time callers. I'll rename that one to RERERE_WARN_LOCKED so it doesn't look like the option's flag, which stays RERERE_NOWAIT. > An alternative could be to instead call `rerere_gc()` directly, and if > so we wouldn't have to add this flag at all. But that may result in some > bigger changes, so I'll leave it up to you to decide. I tried it. It is six lines in builtin/gc.c, but rerere_gc() dies when it can't take the lock. A manual or scheduled "git maintenance run" then dies with the lockfile's message and exit code 128, where it now reports "task 'rerere-gc' failed" and exits with 1. The rerere-gc tests in t7900 fail too, since their helper looks for the "git rerere gc" child. So I'd keep the option for this series. Say if you'd rather have the direct call. I'll wait a day or two for other comments before I send v6. Thanks, Thomas