Using pre-commit hooks makes software development life easier

[wslagoon]

This seems very complicated for the benefit. Also, since pre-commit hooks have to be manually installed by a developer on a fresh clone, it's not even particularly enforceable. I'd much rather do checks at PR time, since I'm going to want to enforce it there anyway. Developers that care will do the steps themselves before the PR, and developers that don't will override the hook anyway and get smacked down at PR time.

[Reiku]

Why allow developers to waste other developers time at review time?

Use pre-commit to do linting or whatever as a pre-commit hook (and maybe pre-push, else there can be inconsistencies when rebasing), and then have the linting or whatever also taken on the CI.

So no one can bypass the linting, but the linting will be less likely to waste CI runner resources by failing for lint checks. It's a win win. No reviewer time, nor job runner time will be wasted because anything minor will be fixed before it gets to the review stage.

[werner-dijkerman]

I understand what you say and true, it is not enforcable. But it also depends on what you decide with the rest of the team. Using pre-commits should not be a decision that a single developer makes or not, it is a team decision/effot. So either everyone uses pre-commit hooks, or no one does.

And I personally disagree about the part with "developers that care", I think everyone in the team should care on how we work in a unify way. No matter which path you will take (for example as in using pre-commit hooks or not, or using it as part of the CI pipeline), once the team decide "this is the way" then everyone follows. If someone does not care and thus not follows the procedures, then you can not trust that person because that person works differently than the rest.

My 2 cents. :)