Well we are in a discussion about pre-commit hooks. Pre-commit hooks run on local wip commits.

Well, unless you inhibit them with `-n`. Which I would for WIP commits.

Then what’s the point? Just leave them off and run the tests when you want to run them.

Because 99% of my commits are not WIP commits. So I almost always want to run them.

Hell, even most WIP commits will pass the tests (e.g. tests are not yet added for the new code), so I'd run them then too.

Some people write tests first.

And commit in such that the final timeline has broken tests for half of commits?

Sounds like an awful way to live your life.

No, we're not talking about the final timeline. That is finalised when (or if) code is merged to the mainline. We're talking about what happens when the command "git commit" is executed.

Ok, if you're talking about just WIP commits that will be squashed and will never be part of mainline, then shrug.

For me that's a tiny proportion of commits. I'd rather avoid taking a whole finished feature branch and then spend more time cleaning up a sloppy commit history.

Sure, sometimes it's correct to squash, but for nontrivial changes I go with https://github.com/google/eng-practices/blob/master/review/d...