This depends on mindset: what do you consider the primary building block for a changeset - the changes, as made by the developer in chronological order or chang

This depends on mindset: what do you consider the primary building block for a changeset - the changes, as made by the developer in chronological order or changes that are related by logic, despite the time (and order) in which they were made. I favor the latter approach - developers in the future will have no use in knowing the different approaches I attempted before coming to the actual solution - that is noise. What they should care about (IMO) are logical commits with related changes. Additionally, "preserving detailed history" makes cherry-picking fixes across multiple release branches a royal pain: not everyone has the luxury of having on single, ever-green release branch. So having a feature/fix in a single, self-contained commit that hides away the actual history is a good thing in this scenario (with the added bonus of not running into fluff/half-cooked commits when running git bisect)