A bunch of wip wip2 wip3 commits don't add any value, and make the log harder to read. But if you break a bigger PR down into "added feature x", "tests for feature x", "refactored y to support x" -- the commits are easier to read and provide valuable "why" history when you're trying to figure out what happened two years later.
That's more about the contents of the merged commits than anything else. Modifying the commit message(s) fixes that, as long as that's what the commits actually did.
Aside from that, how are "a fix for a bug" style commits not "clean"? If merge 123 into master contains a bug that is fixed in a future merge 1234, it doesn't seem "dirty" to me; quite the opposite actually, as it tracks what actually happened.
Now, "wip" style commits shouldn't be on whatever main branch everyone is working on: that's what branches are for. And if everyone is just working off the main branch and committing directly to it, that's an organizational deficiency; not one that VCS can solve.
Modifying commit messages is rewriting history, right?
> “wip” style commits shouldn’t be on whatever branch everyone is working on
Agreed! We aren’t talking about rewriting shared branch history, we are talking about removing the “wip” commits made hastily and locally before pushing them. Sounds like we agree!
