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.

▲

nitnelave 6 hours ago | parent | next [-]

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.

	▲	sa46 4 hours ago \| parent [-]
		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.

▲

chuckadams 4 hours ago | parent | prev [-]

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.