You can check inside the hook if you're in the middle of the rebase, and exit the hook early.

This is what we have in our hooks:

    if [ -d "$(git rev-parse --git-path rebase-merge)" ] || \
       [ -d "$(git rev-parse --git-path rebase-apply)" ] || \
       [ -f "$(git rev-parse --git-path MERGE_HEAD)" ]; then
        exit 0
    fi

Thanks for this, I can’t believe this never occurred to me to try to do.

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.

I personally avoid pre-commit hooks and instead use git rebase -x "hook" to ensure my commits are not broken

I love hooks in general but I definitely have a thing against hooks that aren't read-only (except maybe some autogenerated stuff that "can't go wrong").

The hooks can fail my commit all they want, but I don't want them actually changing anything I've done, which definitely implies no reformatting in hooks.

maybe, because i really don't have the problem you're describing.

yes, formatters run on every commit. not only during rebase, but also every commit beforehand. if that is done consistently, the formatter does not cause merge conflicts.

merge conflicts during rebases due to variable name changes occur without commit hooks, too.

> if you have a hook that is designed to introduce said white changes at each commit of a rebase them you are going to have frequent merge conflicts.

Only if you rebase commits prior to the introduction of the hook. Otherwise that whitespace change should be already there in the old commits.

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.

> For TS projects I just run formatting, type, and lint checks.

For formatting I find that it's clearly preferable to lean on the IDE and apply the source code formatter at each file save, and apply it only to the file you are touching. Type checks should be performed right before running unit tests, for the same reason unit tests are executed.

Yeah of course, same here for formatting. But in the world of LLM agents it's pretty easy to have formatting issues sneak by without the IDE being involved. It's a very quick and easy check.

For type checking, I guess that makes sense if your unit tests are small and quick. At work type checking our entire codebase can take like 10-15 seconds with a cold cache, but running all unit tests takes 20 minutes (and multiple shards in CI). Seems like a no brainer to just run the cheap one more often.

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.