On Thu, May 2, 2019 at 10:07 PM Jeff King <peff@xxxxxxxx> wrote: > > On Thu, May 02, 2019 at 04:45:36PM +0300, Aleksey Midenkov wrote: > > > > 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. > > Since the decision of whether to use the locks is dependent on the > operation being performed, it's an environment variable and not a config > option. And there's also tradeoff for doing it. If git-status will not take locks, it cannot update the index to save refresh information and reuse the next time. git-status may become more and more expensive over time (*). Setting a config variable for this does not sound like a good idea at all. The same for setting GIT_OPTIONAL_LOCKS=0 in ~/.bashrc to "fix" the problem once and for all. I might take a stab at the "wait and try to hold the lock again, doing necessary verification after if needed" idea. It sounds like the right way to go and we haven't had problems with refs doing the same thing (have we?). (*) not entirely true since other commands can also refresh and save. But in the ideal world when optional locks are used for all optional updates, it's true. > You should be able to do: > > GIT_OPTIONAL_LOCKS=0 kdevelop > > and any commands run by kdevelop will avoid taking locks when they can > (but for now, the only command which does this is git-status anyway). -- Duy
