alt Hacker NewsAnother commenter is currently down voted for something similar, but I'll share my controversial take anyways: I hate pre-commit hooks.
I loathe UX flows where you get turned around. If I try to make a commit, it's because that I what I intend to do. I don't want to receive surprise errors. It's just more magic, more implicit behavior. Give me explicit tooling.
If you want to use pre-commit hooks, great! You do you. But don't force them on me, as so many projects do these days.
Replies
But no one forces pre-commit hooks onto you? You can just not install the hook into git and run the tool manually instead.
I use exactly one such hook, and that's to add commit signoff because of a checklist-compliance item called DCO that fails all PRs unless they have the sign-off trailer added by `git commit -s`. I've long argued that we should be enforcing actual signed commits instead, but compliance has never been about doing the sensible thing.
It's as simple as a script with a cp command that I run after any clone of a repo that requires it; certainly doesn't require anything as elaborate as a hook manager.
Client-side pre-commit hooks are there to help you in the same way that type checking (or a powerful compiler) is there to help you avoid bugs. In particular with git, you can skip the hooks when committing.
Now, if the server enforces checks on push, that's a project policy that should be respected.