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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.