Can people give examples of how they use pre-commit hooks that _cannot_ be replaced by a combination of the following?

* CI (I understand pre-commit shifts errors left)

* in editor/IDE live error callouts for stuff like type checking, and auto-formatting for things like "linters".

Do you run tests? How do you know _which_ tests to run, and not just run every test CI would run, which could be slow?

It’s a question of feedback time and consistency: e.g. if you run Prettier/Ruff in CI, someone has to wait minutes rather than milliseconds and you either have to fix build failures or grant your CI system commit privileges and deal with merge conflicts. This also means more total CI runner usage while someone’s laptop probably has 10 idle cores.

If it’s on a pull/merge request, you’re wasting reviewer time.

If the hook is blocking secrets, you can’t un-push it with 100% certainty so you have to revoke credentials.

For texts, I tend to have the equivalent of “pytest tests/unit/“ since those are fast and a good sanity check, especially for things like refactoring.

I also run our pre-commit checks in CI for consistency so we’re never relying on someone’s local environment (web editors exist) and to keep everyone honest about their environment.

> Can people give examples of how they use pre-commit hooks that _cannot_ be replaced by a combination of the following?

I can't, because the point of our pre-commit use isn't to run logic in hooks that can't be run otherwise.

e.g. We use pre-commit to enforce that our language's whitespace formatting has been applied. This has the same configuration in the IDE, but sometimes devs ignore IDE warnings or just open files in a text editor for a quick edit and don't see IDE warnings or w/e.

"Replaced by CI" isn't really meaningful in our context - pre-commit is just a tool that runs as part of CI - some things get done as pre-commit hooks because they're fast and it's a convenient place to put them. Devs are encouraged to also run pre-commit locally, but there's no enforcement of this.

> Do you run tests? How do you know _which_ tests to run, and not just run every test CI would run, which could be slow?

We have performance metrics for pre-commit hooks and pre-push hooks. I forget the exact numbers, but we want stuff to "feel" fast, so e.g. if you're rebasing something locally with a few dozen commits it should only take seconds. Pre-push hooks have a bit more latitude.