Re: [PATCH v2] config: retry acquiring config.lock, configurable via core.configLockTimeout
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jul 7, 2026, 11:39 UTC
- Message-ID
- <10bb26f4-38e7-1bb8-d2d9-4d3e2ef52adc@gmx.de>
- In-Reply-To
- <f449d0db-0434-f870-c69f-793f2b096816@gmx.de>
Hi,
On Thu, 28 May 2026, Johannes Schindelin wrote:
Show 15 quoted lines
> 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