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

[Aleksey Midenkov <midenok@gmail.com>]

On Wed, May 1, 2019 at 9:36 PM Jeff King <peff@peff.net> 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
> all.

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.

>
> -Peff



-- 
All the best,

Aleksey Midenkov
@midenok