Web lists-archives.com

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

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