Re: Bug: fatal: Unable to create '.../.git/index.lock': File exists.

From: Jeff King <peff@peff.net>
Date: May 1, 2019, 18:36 UTC
Message-ID: <20190501183638.GF4109@sigill.intra.peff.net>
In-Reply-To: <CAF8BazBBP53uhh+oOroFuVCEL-FaqJheSYX5Q5_NQxGRt=g_xA@mail.gmail.com>

On Wed, May 01, 2019 at 10:15:19AM +0300, Aleksey Midenkov wrote:

Show 8 quoted lines

> > 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 all.

-Peff