Re: Bug: fatal: Unable to create '.../.git/index.lock': File exists.
- Date: Thu, 2 May 2019 16:45:36 +0300
- From: Aleksey Midenkov <midenok@xxxxxxxxx>
- Subject: Re: Bug: fatal: Unable to create '.../.git/index.lock': File exists.
On Wed, May 1, 2019 at 9:36 PM Jeff King <peff@xxxxxxxx> wrote:
> On Wed, May 01, 2019 at 10:15:19AM +0300, Aleksey Midenkov wrote:
> > > Usually when we see racy contention on index.lock, the culprit turns out
> > > to be another unrelated git process refreshing the index. Do you have
> > > anything else running which might be using "git status" (e.g., magit in
> > > emacs, vim git integration, etc)?
> > kdevelop which is git-aware. But if git fails on concurrent operation
> > this is still not good. I would expect it to wait until lock releases
> > for some time.
> Historically Git does not wait for locks because whoever is holding the
> lock is likely to invalidate the changes we're proposing to make by
> taking the lock in the first place. We've softened on that a bit in
> recent years (e.g., ref updates now retry with a timeout to accommodate
> things like reflog pruning), but I don't think the index code does.
> If the other entity holding the lock is just updating the stat
> information in the index, that's probably OK. If it's actually
> manipulating the index, I think we'd have to give more thought about
> whether that's safe.
> Assuming that kdevelop is just running "git status" in the background,
> though, there's an easier solution. If it uses "git --no-optional-locks
> status" instead, that will instruct it not to take the index lock at
And can we disable optional locks at git configuration level? Because
changing source code of each application that is not aware of this
option is not an easier solution.
All the best,