While I like the idea of rearranging commits to convey a nice (but "not how it originally happened") development sequence, I think in practice this matters less than (say) good commit messages, or the difference between merging and rebasing.
(--fixup type commits aside).
Practical benefits from not squashing history:
- Can bisect to find bug introduction.
- Can annotate/praise/blame to find who/when some change was made.
- Adam Tornhill's "Code as a Crime Scene" argues that it'd be beneficial to
consume VCS history to provide health metrics on the codebase. (e.g. use VCS to check which sources have many contributors (thus potentially high defects), or check for "lost knowledge" from developers who have left).
- Can build/run an older version of the software.
But is there really a big advantage from putting time into maintaining a sequence of commits?
EDIT: Ah, I see another comment point out that "maintaining a nice history" tends to mean fixing very borked commits. That makes sense. :-)
All of these advantages don't make sense if half your commits are broken versions of the software. Rebasing helps ensure that each commit is valid. That's important for the reasons you mention. Having a log of what you actually did is not important.
(--fixup type commits aside).
Practical benefits from not squashing history:
- Can bisect to find bug introduction.
- Can annotate/praise/blame to find who/when some change was made.
- Adam Tornhill's "Code as a Crime Scene" argues that it'd be beneficial to consume VCS history to provide health metrics on the codebase. (e.g. use VCS to check which sources have many contributors (thus potentially high defects), or check for "lost knowledge" from developers who have left).
- Can build/run an older version of the software.
But is there really a big advantage from putting time into maintaining a sequence of commits? EDIT: Ah, I see another comment point out that "maintaining a nice history" tends to mean fixing very borked commits. That makes sense. :-)