On Apr 02, 2015, at 12:06 PM, Jason R. Coombs wrote:
The way I see it, a squash of history or massive patch file loses history. It loses details about the thought process of the implementer. It masks mistakes and obscures motivations. It also masks decisions made in the merge operation, further hiding potential problems.
In general I agree. Coming from bzr, it's very rare that merges get rebased first, but bzr has a strong "mainline-of-development" view that tends to make squash-before-merge unnecessary. diffs, bisects, logs, etc generally follow first-parents by default so you don't see all the subcommits, unless you want to, which sometimes you do.
git doesn't really follow this tradition (although some commands have an option to follow first parents). Not sure about hg.
Cheers, -Barry