Comment by xyzzy_plugh
10 hours ago
Another 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.
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.
The problem is that pre-commit hooks are much slower with a much higher false-positive rate than type checking.
Pre-commit checks should be opt-in with CI as the gate. It's useful to be able to commit code in a failing state.
No one forces you to install the pre-commit hook on your local checkout so what you're suggesting is universally the case. You're perfectly free to just run it manually or let it fail in CI or use `--no-verify` when committing to skip the hook if you install it.
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.