Don't lock git repo when checking status #2648
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix "fatal: Unable to create '.git/index.lock': File exists." when doing
fugitive commands.
Since upgrading fugitive from fugitive@7c1f2ed to 5f0d280, I
occasionally hit this lock error when using `ZZ` to save and close the
fugitive rebase window.
I have no other windows or tabs open (nothing that might be invoking
git). I get the error around 1 in 5 attempts on a larger git repo and
less often on small repos (like vim-fugitive's repo).
However, I have airline and have the git branch name and dirty status in
my **statusline**. A minimal repro of just sensible, fugitive, and
vim-airline with no custom airline configuration produces the issue. If
I use `:AirlineToggle` to turn off the statusline, it seems to go away.
Airline uses fugitive to get the branch name (with `FugitiveHead()`) and
strip the `fugitive://` name from buffers (with `FugitiveReal()`).
I tried removing ShellCmdPost fugitiveline.vim and that *seems* to fix
it, but I don't understand why.
What makes more sense is that the dirty check is asynchronous and is
trying to check status when fugitive is trying to rebase. Because the
repo is large, it takes longer to get status (true for just running `git
status` too).
I have async enabled:
:echo g:airline#init#vim_async
1
tpope suggests using --no-optional-locks to solve:
tpope/vim-fugitive#1624
That also appears to fix the issue.
This flag was introduced to git in 2017 which would make airline fail on
older gits:
git/git@27344d6
There's also GIT_OPTIONAL_LOCKS=0 environment variable, but that
requires more infra work.
|
Makes sense. I would think a 6 year old git requirement should be okay. But who knows what ancient versions are people use. After all I sometimes still have to use an ancient vim 7.4 on some CentOS boxes.. So thanks, looks good to me! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix "fatal: Unable to create '.git/index.lock': File exists." when doing fugitive commands.
Since upgrading fugitive from tpope/vim-fugitive@7c1f2ed to 5f0d280, I occasionally hit this lock error when using
ZZto save and close the fugitive rebase window.I have no other windows or tabs open (nothing that might be invoking git). I get the error around 1 in 5 attempts on a larger git repo and less often on small repos (like vim-fugitive's repo).
However, I have airline and have the git branch name and dirty status in my statusline. A minimal repro of just sensible, fugitive, and vim-airline with no custom airline configuration produces the issue. If I use
:AirlineToggleto turn off the statusline, it seems to go away.Airline uses fugitive to get the branch name (with
FugitiveHead()) and strip thefugitive://name from buffers (withFugitiveReal()).I tried removing ShellCmdPost fugitiveline.vim and that seems to fix it, but I don't understand why.
What makes more sense is that the dirty check is asynchronous and is trying to check status when fugitive is trying to rebase. Because the repo is large, it takes longer to get status (true for just running
git statustoo).I have async enabled:
:echo g:airline#init#vim_async
1
tpope suggests using --no-optional-locks to solve: tpope/vim-fugitive#1624
That also appears to fix the issue.
This flag was introduced to git in 2017 which would make airline fail on older gits:
git/git@27344d6 There's also GIT_OPTIONAL_LOCKS=0 environment variable, but that requires more infra work. Not sure if airline already supports 6 year old git?