Periodical background 'git status' in Git Extensions interferes with interactive work

Question

I use Git Extensions and command line simultaneously (I use git-tfs, so should use command line for push/fetch).

But if I try push changes from command line with not closed Git Extensions window, it often finish with error

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

reason obvious - Git Extensions periodically execute git status which create lock file and prevent push.

I found solution - close Git Extensions before work in console, but it not very handy and I often forgot it.

What else can I do here? May be somehow disable create lock for git status?

Answer 1

Git 2.14 proposes already a background refresh for git status, that Git Extensions might end up benefiting from:

See commit 5e83cca (27 Nov 2017) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit e6bf6af, 13 Dec 2017)}

git-status.txt: mention --no-optional-locks

If you come to the documentation thinking "I do not want Git to take any locks for my background processes", then you may easily run across "--no-optional-locks" in git.txt.

But it's quite reasonable to hit a specific instance of the problem: you have "git status" running in the background, and you notice that it causes lock contention with other processes. So you look in git-status.txt to see if there is a way to disable it, but there's no mention of the flag.

Let's add a short note mentioning that status does indeed touch the index (and why), with a pointer to the global option. That can point users in the right direction and help them make a more informed decision about what they're disabling.

So the git status man page now reads:

BACKGROUND REFRESH

By default, git status will automatically refresh the index, updating the cached stat information from the working tree and writing out the result.
Writing out the updated index is an optimization that isn't strictly necessary (status computes the values for itself, but writing them out is just to save subsequent programs from repeating our computation).
When status is run in the background, the lock held during the write may conflict with other simultaneous processes, causing them to fail.
Scripts running status in the background should consider using git --no-optional-locks status.

If that last sentence could find its way in the embedded Git packaged in Git Extensions, that would solve your issue.

Answer 2

While the issue is caused by git status locking, it can also be mitigated with a setting change from Git Extensions without needing to close Git Extensions before opting to perform Git work elsewhere: I do most of my work from "elsewhere" so closing Git Extensions is not a fun long-term strategy :}

From twinsec on https://github.com/cmderdev/cmder/issues/1044 -

For anyone ran into the same issue with index lock, there's a workaround [by]

• disabling Settings -> Git Extensions -> Performance -> Show number of changed files

[..] so that Git Extensions won't call git status as soon as any file updates which [is] blocking the current processing git commands and introducing the lock.

Hope this help for you guys.