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.
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
fiI don't think your argument is grounded on reality. Applying whitespace changes does create merge conflicts, and 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.
Keep also in mind that minor changes such as renaming a variable can and will introduce line breaks. Thus even with a pristine codebase that was formatted to perfection you will get merge conflicts.
> 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.
You're letting the world know you have little to no programming experience.
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.
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.
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.
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.
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
Of course tests are slow. If they're fast they're skipping something. You probably want to be skipping something most of the time, because most of the time your change shouldn't cause any side-effects in the system, but you definitely want a thorough test suite to run occasionally. Maybe before merge, maybe before release, maybe on some other schedule.
Each individual change might be fine in isolation but cause excessive memory pressure when accumulated with other changes, for example. Unit tests won't catch everything, integration & functional (hardware in-the-loop) tests are needed. I even sometimes have to run tests in a thermal chamber repeatedly to cover the whole -40-105°C temperature range, since the firmware I work on runs on hardware that allows that range & performance varies with temperature.
And what about tests that only need to run intermittently, such as broken link checkers?
Or you care about your formatting and don't want to throw them away.
But it requires me to remember to set that up for each repo, and this is a massive pain. I'd like to be able to have a "clone with hooks" option, but I don't think anyone has found a way of making that work well without leaving people in danger when they clone a random repo.
I've only encountered those on the server side.
Edit: `git config --global core.hooksPath D:\GitHooks\` is what I needed!