Editing history let's people hide information, intentionally or not. You are bold to claim you know what future people need information wise better than them.
What's it matter if you have an extra commit to remove a file before merge? Perfectly valid, and doesn't hide anything.
Caring more about a "visually pleasing log" when you can care about an information rich log doesn't jive with me. Logs aren't supposed to be "clean"
If I want features in two branches, I make two branches. Cherry pick also is bad for most people, most of the time.
I care about having a commit log that's useful and easy to scan through, it's not about it being "visually pleasing". Having a dozen "oopsie" commits in the log doesn't make my life any easier down the road, all it does is increase noise in the history.
Again, once something hits `main` or a release/maintenance branch then history gets left the hell alone. But there really is no context to be gained from me fixing stupid things like typos, stripping out printf() debug statements, etc. being in the commit logs before a change gets merged.
> Editing history let's people hide information, intentionally or not. You are bold to claim you know what future people need information wise better than them.
You're already deciding what information is important to the future when you decide at which points you commit.
Reductio ad absurdum: why not commit every keystroke, including back spaces? By not including every key stroke, you are hiding information from future people!
Caring more about a "visually pleasing log" when you can care about an information rich log doesn't jive with me. Logs aren't supposed to be "clean"
If I want features in two branches, I make two branches. Cherry pick also is bad for most people, most of the time.