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:

git apply /path/to/patch_with_id

And if you have a conflict with a file, like a generated CSS file, you can exclude that from the patch:

git apply /path/to/patch_with_id --exclude views/static/css/app.css