Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.git/index.lock can be held when vscode is in background because of GitLens calls to git status #163

Closed
joelhock opened this issue Oct 9, 2017 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@joelhock
Copy link

joelhock commented Oct 9, 2017

  • gitlens|eam|5.5.0
  • VSCode Version: Code 1.17.0 (be377c0faf7574a59f84940f593a6849f12e4de7, 2017-10-05T06:07:51.906Z)
  • OS Version: Darwin x64 16.7.0

Steps to Reproduce:

  1. switch from vscode to terminal (so that vscode is in the background)
  2. touch file (or do something that touches files, like a git pull --rebase)
  3. see that getStatusForRepo('/my/path/to/repo') is called in GitLens output channel
  4. if operation in terminal needs .git/index.lock (e.g. a git rebase operation), it may fail, since the GitLens getStatusForRepo may be holding the lock.

vscode's grabbing of the .git/index.lock has been the source of a number of issues filed against it, the main one of which is microsoft/vscode#11918
other extensions are now being identified that do the same thing, such as:
letmaik/vscode-git-tree-compare#24

The behavior of GitLens can be sidestepped with gitlens.gitExplorer.includeWorkingTree": false, but I think GitLens should either not call git status when vscode is in the background via the mechanism introduced in microsoft/vscode@475fb0e, or it should instruct git (well, future versions of git) to not grab the lock during git status calls via the mechanism in microsoft/vscode#35513

@joelhock
Copy link
Author

joelhock commented Oct 9, 2017

and now that I look at things a bit more, I see that GitLens will call getStatusForRepo in response to the git cache changing, so gitlens.gitExplorer.includeWorkingTree": false is not a complete workaround. the filesystem watch that it controls made the problem worse, so setting it to false can still help mitigate the issue.

@eamodio eamodio added the bug Something isn't working label Oct 10, 2017
@eamodio eamodio added this to the On Deck milestone Oct 10, 2017
eamodio added a commit that referenced this issue Oct 11, 2017
@eamodio
Copy link
Member

eamodio commented Oct 11, 2017

FYI -- I added the GIT_OPTIONAL_LOCKS=0 to GitLens 5.6, but I am currently blocked from adding the background checks by microsoft/vscode#36010

@joelhock
Copy link
Author

thank you!!

@eamodio eamodio removed this from the Soon™ milestone Jul 19, 2019
@wmakley
Copy link

wmakley commented Aug 21, 2019

Happening to me constantly in Windows with WSL remote mode and the latest version of VSCode and Gitlens.

@eamodio
Copy link
Member

eamodio commented Aug 22, 2019

@wmakley Please open a new issue for this and attach logs and a clear description of what you were doing and the error that happened. Thanks!

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants