-
Notifications
You must be signed in to change notification settings - Fork 79
hyper-statusline causes index.lock errors in large repos #32
Comments
I'm not sure what the best approach to solve this issue is. I could check if index.lock exists and based on that delay the call, but it doesn't feel ideal. Any suggestions? ✌️ |
@henrikdahl unfortunately no, this is a little beyond me. not exactly a direct fix, but maybe an option to turn on/off the git status would be helpful. |
I get this same error on a 2.1GB repo. Strange thing is I only see the error on some commands. I don't know if this helps at all, but I would love to help - I've been walking through the middleware events that Hyper exposes and I don't see any obvious events that could better trigger the dirty checks. |
I had to remove |
Took another look at this. Problem is basically that In the latest commit I changed the dirty check to ignore untracked files, which should speed it up immensely and solve the issue for some of you. Another solution could be git-update-index. But I'm not sure that Let me know how it works ✌️ |
I have this problem only when working on a rebase. Random commits are cancelled due to index.lock errors. hyper 2.1.1 |
Ah this has been driving me insane for weeks. I finally tried my rebase in a large repo in Terminal on a whim and it worked and quickly realized this plugin was the issue. |
when in a very large repo (8+gigs), hyper-statusline will interfere with git commands and cause a lock
fatal: Unable to create '<path to repo>/.git/index.lock': File exists. If no other git process is currently running, this probably means a git process crashed in this repository earlier. Make sure no other git process is running and remove the file manually to continue.
The text was updated successfully, but these errors were encountered: