zero delay on commit, but then an entire CI run and feedback loop just to fix a linter or formatting issue

The solution could be a pre-push hook. I am also not a fan of pre-commit hooks because I just want to commit my wip changes. Not stash. Commit.

It's fine if the auto formatting tool hasn't been run. If the pre-commit hook changes my files silently, that is a big no-no for me.

I have had tools break things before and it makes it very hard to work out what happened.

Having it fail to push means I get to choose how to fix up my commits - whether I want a new one for formatting changes etc or to go back and edit a commit for a cleaner public history.

I used to think pre-push was better than pre-commit but at some point I realized I was actually just kicking the can down the road and leaving bigger problems for myself. It's not downsides-free, but it's the better compromise for me.

100% agree on hooks being readonly.

Username oddly relevant to context btw.

Couldn't disagree more.

Waiting for a CI step to tell me something's wrong when I could've found out locally is a waste of time.

Sure, I can hand-run checks locally, but having a way of doing it "automatically" pre-push gives me consistency and saves time.

That's fine, but it shouldn't be enforced on all contributors. What matters is that failures don't get merged, not that they don't get committed.

Yeah.

As long as "don't get merged" includes squashing so that whatever your (non)hooks didn't catch locally don't end up causing failures for rebases/merge conflict resolutions for others (assuming there are repo-level hooks people are expected to be using).