From: Patrick Steinhardt Date: Thu, 01 Oct 2026 11:19:35 GMT Subject: Re: [PATCH v5 2/3] rerere: add "gc --auto" that skips a held lock Message-ID: In-Reply-To: On Thu, Oct 01, 2026 at 10:08:16AM +0200, Thomas Bachem wrote: > 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. Ah, right, that makes sense. Let's keep the hidden option in that case. Thanks! Patrick