The pre-commit project is immensely helpful.You can learn about pre-commit at their very helpful documentation page. I use it on every project at home and work to run a few checks and ensure my code is formatted in a uniform fashion every time I commit it to the repo.
The other day, I had an issue during the pre-commit cycle.
Another process changed a file while pre-commit was running its tasks, and as a result, my repository was in a state where it seemed I lost every modified file. It seemed like I lost hours of workMental note: I need to work on doing smaller commits more often. .
Now, I don’t think this is a problem with pre-commit. I couldn’t reproduce this situation after many attemptsMy best guess is that it was a race condition, where Gulp was processing a modified file and finished just as I was running pre-commit. .
But still, looking at your code repo that shows very few modified files, when a moment before there were many modified files, is a very troubling and anxiety-rich experience.
If you experience this, I want to give you hope.
Your files are not lost
For better or worse, this was not the first time I had this anxious feeling with a git repo in recent weeksI really need to make smaller commits more often! (But git reflog is a lifesaver! . As a result, I had this thought pop up: “Your files are not lost.”
Pre-commit stashes all your modified files into a patch file and stores them in a central place, usually $HOME/.cache/pre-commit .
So, if your repo is in a state where it seems you lost your modified files, look at the log from your most recent commit. In there, you should see pre-commit mention a specific patch file name.
To restore your repo, run this command: