Repository navigation
Git index becoming corrupted #524
Description
I've been encountering an error where the git index becomes corrupted and staged files are effectively get a git reset --hard HEAD. That mean I lose my changes. Fortunately, I usually have the file open in a buffer in my text editor and I can undo (restoring my changes), save, restage, and commit successfully. I would think this is a serious issue, but I'm wondering if I am the only one effected by this.
Here is an example of the output I regularly see.
Running pre-commit hooks
Check for trailing whitespace....................[TrailingWhitespace] OK
Analyze with RuboCop........................................[RuboCop] OK
✓ All pre-commit hooks passed
Unable to restore working tree after pre-commit hooks run:
STDOUT:
STDERR:unable to refresh index
I have not found a means to reliably reproduce the issue. This happens to me about every other day. I just set the OVERCOMMIT_DEBUG env var, so hopefully next time I see this bug, I will have something more helpful to post in the logs.
The current version of git I am running is 2.15.0.
Activity
trotzig commentedon Nov 28, 2017
I believe your changes aren't lost in this situation. If you check
git stash list, look for"Overcommit:". You should be able to apply that stash manually.This has come up a few times before. There's an open issue about making the console output better (#504) and there's a good discussion in #135.
mrinterweb commentedon Nov 29, 2017
Good to know. Now that you mention it, I do see the stash entries. Regardless, I don't believe that this should be considered a logging output bug, but I can see how better output could help people figure out what went wrong. If there is a problem, the commit should fail and staged items should not be automatically stashed, in my opinion.
trotzig commentedon Nov 29, 2017
Yeah, I agree the bug here isn’t the output. Anything you can find to track this down further is of great help!
sds commentedon Jan 28, 2018
Going to close as it's hard to determine if this is truly an issue with Overcommit. Oftentimes you will hit issues when working with systems that use
inotifyor other file system watchers which changes files while Overcommit itself is making changes. This can cause issues restoring the working tree.As @trotzig pointed out, you should always be able to restore from the stash.
If you manage to provide a reproducible example, happy to explore further. Thanks!
Support hook side effects without stashing repository changes (#939)