| ▲ | btreecat 6 hours ago | |
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. | ||
| ▲ | snuxoll 6 hours ago | parent [-] | |
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. | ||