Comment by nine_k
6 hours ago
A bit less enraged: pre-commit hooks should be pure functions. They must not mutate the files being committed. At best, they should generate a report. At worst, they could reject a commit (e.g. if it contains a private key file included by mistake).
> e.g. if it contains a private key file included by mistake
Thanks - this is the first example of a pre-commit hook that I can see value in.
Remember that such key will be copied into the repository on `git add` already and will stay there until garbage collected.
In my experience pre-commit hooks are most often used to generate a starting commit message.
To put it more bluntly, pre-commit hooks are pre-commit hooks, exactly what it says on the tin. Not linting hooks or checking hooks or content filters. Depending on what exactly you want to do, they may or may not be the best tool for the job.
To put it even more bluntly, if you are trying to enforce proper formatting, pre-commit hooks are absolutely the wrong tool for the job, as hooks are trivially bypassable, and not shared when cloning a repo, by design.