Re: [PATCH v5 07/11] maintenance: take a lock on the objects directory

From: Derrick Stolee <stolee@gmail.com>
Date: Sep 21, 2020, 13:43 UTC
Message-ID: <368d7c1f-b8b2-8bed-ead4-047019125435@gmail.com>
In-Reply-To: <87d02fi75p.fsf@evledraar.gmail.com>

On 9/21/2020 9:36 AM, Ævar Arnfjörð Bjarmason wrote:

Show 8 quoted lines

> There's now two different lock strategies in builtin/gc.c, the existing
> one introduced in 64a99eb476 ("gc: reject if another gc is running,
> unless --force is given", 2013-08-08) where we write the hostname to the
> gc.pid file, and then discard the lockfile depending on a heuristic of
> whether or not it's the same etc., and this one.
> 
> With this as an entry point we'll entirely do away with the old one
> since we don't use the "gc --auto" entry point.

Users could still erroneously launch two `git gc` commands concurrently and that will not use the maintenance.lock file. The GC lock is worth keeping around until we redirect the `gc` command to be an alias that runs `git maintenance run --task=gc [options]`.

Show 6 quoted lines

> All of that may or may not be desirable, but I think a description in
> the docs & tests for how these lock files should interact would be
> helpful. E.g. writing a different hostname in the gc lockfile and
> setting the time on it with with "test-tool chmtime" will cause it to
> plow ahead, but doing the same for "git maintenance" will stop it in its
> tracks no matter the time or content.

Thanks for the pointers to create this test. I'll try to get to it soon. For now, here is a tracking issue [1].

[1] https://github.com/gitgitgadget/git/issues/737

Thanks, -Stolee