From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 07 Jul 2026 18:16:02 GMT
Subject: Re: [PATCH v2] config: retry acquiring config.lock, configurable via core.configLockTimeout
Message-ID: <xmqq8q7m4qe5.fsf@gitster.g>
In-Reply-To: <10bb26f4-38e7-1bb8-d2d9-4d3e2ef52adc@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Thu, 28 May 2026, Johannes Schindelin wrote:
>
>> On Sun, 17 May 2026, Joerg Thalheim wrote:
>> 
>> > I matched the core.filesRefLockTimeout naming rather than reusing
>> > microsoft/git's core.configWriteLockTimeoutMS, but can switch if the
>> > downstream compat matters more.
>> 
>> I see that there is quite a bit of precedent for naming a config setting
>> `*Timeout` and implying that it specifies milliseconds, e.g.
>> https://git-scm.com/docs/git-config#Documentation/git-config.txt-corefilesRefLockTimeout
>> 
>> In general, I am pretty wary of unit-less numbers [*1*], that's why I
>> chose that "MS" suffix. However, the prior art in Git is clear, and I
>> should not have missed it. Therefore, I have no objections against
>> `core.configLockTimeout` as-is; I'll take care of providing a smooth
>> upgrade path in Microsoft Git.
>
> For the record: I meant this feedback as _supporting_ the patch. Now I see
> it is stalled... I do not really see any reason for this to be blocked
> from promoting to `next` and then `master`, though.
>
> Ciao,
> Johannes

Heh, this paragraph

    microsoft/git carries a similar patch (core.configWriteLockTimeoutMS,
    default off) for Scalar's tests. Defaulting to non-zero here because
    the worktree case fails silently.

in the proposed log message was enough to convince me that you'd be
favor of it.

I think the "Waiting for response(s) to review comment(s)." is for

    So I'd rather lean towards dropping the cache and keeping the
    repository parameter.

that was expressed in a separate review in <agrIrGwSMFlKTx9x@pks.im>
and haven't been responded to.

Thanks for pinging.