> Optimizing for a pretty looking git history is probably the most foolish thing to focus on
It's not about "pretty"; commits are a form of _communication_. Do we send emails without editing before hitting send? It's a means to optimize for easier reviews through better comprehension of the changes, which also leads to faster reviews. Our colleagues don't want to read a bunch of intermediate commits.
> If you are doing anything that involves rewriting the history you are doing it wrong.
> It's not about "pretty"; commits are a form of _communication_. Do we send emails without editing before hitting send?
Writing clear, atomic commits is a good idea regardless of whether you use rebase or not.
In your email analogy, rebasing would be altering previous messages in the chain. That doesn't make rebasing look good!
> > If you are doing anything that involves rewriting the history you are doing it wrong.
> Care to elaborate? What's your general strategy?
Not the parent, but to me the most important part of VCS history is accuracy. Rebasing commits (or cherry-picking them) changes their context; that context can be important for understanding why things were done in a certain way. For example, imagine we're digging through the following history, to understand how some feature 'bar' works:
* Add workaround for Error(foo) in feature bar
|
* Implement feature bar
|
* Bump dependency baz to eliminate Error(foo)
Why was a workaround for Error(foo) added, if that error had already been eliminated? Did that dependency change not work? Is there some more permanent way to eliminate Error(foo)? Is the workaround still needed?
Compare that to the following, more accurate history:
* Merge
|\
| * Add workaround for Error(foo) in feature bar
| |
| * Implement feature bar
* | Bump dependency baz to eliminate Error(foo)
| /
|/
Here it's much clearer what's going on: the dependency change was not in place when that workaround was added. Hence the workaround shouldn't be needed anymore. Rebasing the 'feature bar' changes on to the 'dependency baz' changes throws away that information.
It's not about "pretty"; commits are a form of _communication_. Do we send emails without editing before hitting send? It's a means to optimize for easier reviews through better comprehension of the changes, which also leads to faster reviews. Our colleagues don't want to read a bunch of intermediate commits.
> If you are doing anything that involves rewriting the history you are doing it wrong.
Care to elaborate? What's your general strategy?