[nolemurs]

You have to think about the purpose of the history.

Git history serves a few purposes. First, it provides an overview of development so that someone can use `git log` to quickly figure out what's been done. Second, it provides context to code changes so that someone using `git blame` can figure out why some code looks the way it does. Finally, it provides a set of distinct points for clean manipulation of history via `git revert`, `git bisect` etc.

From the point of those purposes, there's no real value in a history which accurately reflects the development process. The ideal commit has a few properties: it should address only one concern, it should contain all the immediate code changes addressing that concern, and it should not be overly long. Commits like that make navigating and manipulating the git history easy.

There's nothing wrong with keeping an accurate picture of history. It's just not actually useful.

[filoeleven]

> There's nothing wrong with keeping an accurate picture of history. It's just not actually useful.

Except for the relatively rare cases when it is incredibly useful. But that's why we have the reflog.