Re: [PATCH v2] config: retry acquiring config.lock, configurable via core.configLockTimeout

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 28, 2026, 11:51 UTC
Message-ID: <f449d0db-0434-f870-c69f-793f2b096816@gmx.de>
In-Reply-To: <20260517132111.1014901-1-joerg@thalheim.io>

Hi Joerg,

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.

Thank you, Johannes

Footnote *1*: In general, I am quite wary of unit-less numbers in configurations. There's not only the precedent of Mars Climate Orbiter https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_failure, I also heard a story that seemed to be entertaining only in hindsight where a German car's software improperly interpreted a British speed limit sign to mean km/h instead of mph.