[motorest]

> 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.

I 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.

[rkomorn]

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.

[hambes]

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.

[1718627440]

> 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.