Points 1 to 4 argue against the idea of rebasing as an alternative to merging. I agree with this to some extent, but in practice I notice that the exact point at which a branch began is rarely important. A very rough heuristic for this is "can it be rebased non-interactively?". This effectively means I like "cherry-pick merges", and it would be cool if Git remembered more about the origins of them. Rebases that do require manual adjustment are far more error-prone than merges, and I try to avoid those.
Point 5 and 6.0 are the primary reason I edit history. I want my history to tell a coherent story, not just in commit messages but also in the changes themselves, and that story often doesn't perfectly match the actual road traveled to get to the end. I don't much value mistakes where I forgot to implement half a change while tired at the end of a long workday, or an ill-considered false start. Where such information is valuable I'll write it down in the commit messages of changes that implement what did end up happening.
That brings me to the other points. I very much agree with 6.1 and beyond. Squashing branches removes a lot of valuable information, and it removes the ability to tell that coherent story. In particular:
- There are often small changes or bug fixes that aren't really part of the set of changes, but that just happen to become most relevant while developing this feature. Depending on the specifics these could be merged separately, and I keep them separate.
- Nuances discovered later in the development of a set of changes tend to offer valuable insight, so I want to keep them separate from the rest.
It would be cool if Git remembered more of the specifics of how the end result was reached, but I'm not sure if I would use it much in practice.