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