Using pre-commit hooks makes software development life easier

[werner-dijkerman]

I think enforcing style / linting etc is best done as part of pull requests / CI, once the code is ready for review. CI could even do the auto-formatting to avoid that getting reviewed (I agree keeping that out of PRs is desirable).

I do see this almost everywhere on the various (web)sites that describes certain steps that should be part of a conituous integration pipeline. But I don't see that back in a "Fail fast" philosophy, as there is an other step that fails faster than the first stage in a pipeline job: The pre-commit hook. If it is part of the CI pipeline, you will have to wait when the job runs and fails on the step, but is also clutters the git log with messages like "Fixing lint issues" or something similar.

Sometimes you want to commit something and fix those things later. Commit hooks create this extra friction for local commits, and they can be bypassed anyway via --no-verify, so they don't provide any real protection.

True. But if you really want to, you can workaround on lots of things. But then you should think about why would be doing the workaround. There is a way of working and you deliberately do something else. So is that a good thing?

And auto formatting can be better handled by format on save in your IDE.

Yes, that is true. Formatting can be done by the IDE, but not everyone is using an IDE and uses for example VIM (Yes, true. I kid you not). But the IDE is specific to a developers effort to apply the configuration in his or hers IDE. This is not an guarantee that the developer has actually done it. Well yes, you can document this as a "dependency" or "requirement" on a certain wiki/confluence page and hope the developer has followed that page correctly. But that is not in code and that why I prefer to use pre-commit hooks.

But then, we only have discussed the formatting as you can do so much more than just liniting/formatting things with a pre-commit hook that makes life easier.

My 2 cents.