it's the tools. if they're slow people disable them or shift them right. you want your defect-detection and fixing to shift left

if you're not running auto-format on file-save, your auto-formatter is slow

if you're not running a code checker with auto-fix on pre-commit, your code checker is slow

if you're not running the test-suite on pre-push your tests are slow

if your tooling is slow you need to pick better tooling or make them fast

you want to keep that loop tight and active

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

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.

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.

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.