I would argue that if the pre-commit hooks come in the way of rebasing, either the commit hooks are doing way too much (which is one of the points of the article) or you are creating broken commits during rebasing. If any of the commits you are rebasing is e.g. breaking formatting rules, they shouldn't have been committed that way in the first place.
Yeah there's really no trouble with a pre-push hook that runs common/fast code checks. For TS projects I just run formatting, type, and lint checks. Faster feedback than spinning up a runner in CI and if I don't need it I just tack on --no-verify.
Database integrity constraints fall into the same category.
This entire class of automation is awful and defeats the robustness of the tool itself.
All of these things have terribly unpredictable consequences and tend to fail at the worst moments, such as during a SEV.
You can encode the same rules and discipline in other ways that do not impact the health of the system, the quality of the data, or the ability of engineers to do work.
I'm of the opinion that Git hooks are personal. That's why they're not part of the source code itself. I make extensive use of hooks, but they're tailored to my needs.
Note that you can skip hooks by passing the --no-verify flag to subcommands. Comes in handy when they're slow and you know that you've just fixed the wrong formatting that the previous invocation of your pre-commit hook complained about.
Pre commit hooks shine with fast formatters. Keep the hook under half a second or so and it's great.
pre-commit hooks are awful, they get in the way of interactive rebasing. pre-push is where they belong; save a round-trip through CI.
I would argue that if the pre-commit hooks come in the way of rebasing, either the commit hooks are doing way too much (which is one of the points of the article) or you are creating broken commits during rebasing. If any of the commits you are rebasing is e.g. breaking formatting rules, they shouldn't have been committed that way in the first place.
Yeah there's really no trouble with a pre-push hook that runs common/fast code checks. For TS projects I just run formatting, type, and lint checks. Faster feedback than spinning up a runner in CI and if I don't need it I just tack on --no-verify.
Database integrity constraints fall into the same category.
This entire class of automation is awful and defeats the robustness of the tool itself.
All of these things have terribly unpredictable consequences and tend to fail at the worst moments, such as during a SEV.
You can encode the same rules and discipline in other ways that do not impact the health of the system, the quality of the data, or the ability of engineers to do work.
agents trip up over them too.
I'm of the opinion that Git hooks are personal. That's why they're not part of the source code itself. I make extensive use of hooks, but they're tailored to my needs.
Note that you can skip hooks by passing the --no-verify flag to subcommands. Comes in handy when they're slow and you know that you've just fixed the wrong formatting that the previous invocation of your pre-commit hook complained about.