~/.cache/pre-commit: a separate environment for every hook version in every repo
pre-commit builds a full environment for each hook repository and version it meets. One command removes the ones nothing uses any more.
pre-commit installs each hook into its own isolated environment: a Python virtual environment, a Node install, sometimes a whole language toolchain. They live in ~/.cache/pre-commit, one per hook repository and version. Bump a hook's version in one repo and a new environment is built. The old one stays.
Measure it
du -sh ~/.cache/pre-commit
du -sh ~/.cache/pre-commit/repo* 2>/dev/null | sort -h | tailIf PRE_COMMIT_HOME is set, the cache is there instead.
The two cleanup commands
| Command | What it removes | Cost |
|---|---|---|
pre-commit gc | Environments no configuration on this Mac still refers to | Nothing you use |
pre-commit clean | The whole cache | Every hook is rebuilt on next commit |
pre-commit gcgc only knows about repositories where pre-commit has been run. A project you deleted months ago no longer counts as using anything, which is exactly why gc finds so much.
Why some environments are large
- Hooks that need a language runtime pre-commit downloads itself.
- Hooks with heavy dependencies, such as type checkers with stub packages.
- Many versions of the same linter across repositories that update at different times.
For the rest of ~/.cache, see the home cache folder. For Python environments in general, see Python taking up space.
Common questions
Where does pre-commit store its environments?
In ~/.cache/pre-commit, unless PRE_COMMIT_HOME points somewhere else. Each hook repository and version gets its own environment.
What does pre-commit gc do?
It removes cached hook environments that no configuration pre-commit knows about still uses. It does not touch anything a current repository needs.
Is it safe to delete the pre-commit cache?
Yes. pre-commit clean removes it, and each hook is rebuilt the next time it runs, which makes the next commit in each repo slower.