Re: [PATCH v2] lockfile: add PID file for debugging stale locks

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 18, 2025, 00:47 UTC
Message-ID: <xmqqbjjwzkd4.fsf@gitster.g>
In-Reply-To: <pull.2011.v2.git.1765997966593.gitgitgadget@gmail.com>

"Paulo Casaretto via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 7 quoted lines

> The feature is controlled via core.lockfilePid configuration, which
> accepts per-component values similar to core.fsync:
>
>   - none: Disable for all components (default)
>   - all: Enable for all components
>   - index, config, refs, commit-graph, midx, shallow, gc, other:
>     Enable for specific components

As this is about lockfile, you need to decide what should happen when an older version of Git, which is unaware of this new world order where .git/index.pid.lock declares ".git/index is being updated; you should not touch it!", comes to the repository. You, as a user of the updated Git, do want them to stop interferring with the operation on the repository your new Git is making, and it means you should have some way to telling them "do not touch---you do not even understand what is in this repository!".

The established way to do so is with a repository extension. Having core.lockfilePid that is a plain vanilla configuration variable would not affect Git that is not aware of the variable, but unknown repository extension will cause setup.c::verify_repository_format() to stop Git from making damage. Perhaps use extensions.lockfilePID instead?

By the way, we name multi-word configuration variables in CamelCase, but PID (not "process identifier") is an already all-caps word, so core.lockfilePid looks awkward. Call it core.lockfilePID instead? Oh, with "core.lockfilePID" -> "extensions.lockfilePID", perhaps.