Re: [PATCH] config: retry acquiring config.lock for 100ms

From: Jörg Thalheim <joerg@thalheim.io>
Date: May 11, 2026, 09:06 UTC
Message-ID: <91335804a092b09757331cac72092a3835020b3a@thalheim.io>
In-Reply-To: <xmqqcxz2vfpa.fsf@gitster.g>

I am not really sure what you want me to do here. I don't see how git can have this value configurable, given it's about reading the configuration itself. Is the user supposed via command line?

Meanwhile the project I was facing this issue, added the required file lock in its own code, which has since then worked perfectly to fix my use case: https://github.com/raine/workmux/issues/116

May 11, 2026 at 4:32 AM, "Junio C Hamano" <gitster@pobox.com mailto:gitster@pobox.com?to=%22Junio%20C%20Hamano%22%20%3Cgitster%40pobox.com%3E > wrote:

Show 46 quoted lines

> 
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > 
> > > 
> > > This bites in practice when running `git worktree add -b` concurrently
> > >  against the same repository. Each invocation makes several writes to
> > >  ".git/config" to set up branch tracking, and tooling that creates
> > >  worktrees in parallel sees intermittent failures. Worse, `git worktree
> > >  add` does not propagate the failed config write to its exit code: the
> > >  worktree is created and the command exits 0, but tracking
> > >  configuration is silently dropped.
> > > 
> >  This very much sounds like a bug that is worth fixing independently.
> > 
> > > 
> > > The lock is held only for the duration of rewriting a small file, so
> > >  retrying for 100 ms papers over any realistic contention while still
> > >  failing fast if a stale lock has been left behind by a crashed
> > >  process. This mirrors what we already do for individual reference
> > >  locks (4ff0f01cb7 (refs: retry acquiring reference locks for 100ms,
> > >  2017-08-21)).
> > > 
> >  Famous last words :) Experience tells me that any timeout value that
> >  isn't excessive will eventually be hit in some production system. Which
> >  raises the question whether we want to make the timeout configurable,
> >  similar to "core.filesRefLockTimeout" and "core.packedRefsTimeout".
> >  ...
> >  Honestly though, I'm not really sure what to make with this. We could
> >  of course also add some validation that the configuration we want to set
> >  hasn't been modified meanwhile. But that would now lead to a situation
> >  where we have to update every single caller in our tree to make use of
> >  the new mechanism, which would be a bunch of work.
> > 
> >  And adding the timeout doesn't really change the status quo, either. We
> >  already have the case that we'll happily overwrite changes made by
> >  concurrent processes. The only thing that changes is that we make it
> >  more likely for concurrent changes to succeed.
> > 
> We haven't heard any response to these points raised in the message
> I am responding to. Should I still keep the patch in my tree,
> hoping that a responses may come some day? I am tempted to discard
> the topic as it has been quite a while since we last looked at it.
> 
> Thanks.
>