Ideally what you want is a "useful" history, not an actual one. And by "useful" I mean one where the changes in each commit are related to a specific, self-contained update (feature addition, bug fix, etc.).
That way you can branch at any point in the commit history and be sure it'll run cleanly or cherry-pick a change without having to remember everything that it might depend on. And you get exactly what you want and nothing more.
Because some people like to commit a lot...I once had a project where I committed after every red/green cycle. If specs were green and there was uncommitted code, I committed.
That's only useful for me, during tight development loops, not to a historian looking back at what I actually did. So before I push to others, I squash it to a changeset, possibly keeping all the commit messages in the single commit.
Comments
What is the big deal about keeping a clean history?
It's always seemed so much effort than it's worth.
Besides, isn't it better to keep a history of what actually happened? Something about being doomed to repeat it comes to mind...
Ideally what you want is a "useful" history, not an actual one. And by "useful" I mean one where the changes in each commit are related to a specific, self-contained update (feature addition, bug fix, etc.).
That way you can branch at any point in the commit history and be sure it'll run cleanly or cherry-pick a change without having to remember everything that it might depend on. And you get exactly what you want and nothing more.
Because some people like to commit a lot...I once had a project where I committed after every red/green cycle. If specs were green and there was uncommitted code, I committed.
That's only useful for me, during tight development loops, not to a historian looking back at what I actually did. So before I push to others, I squash it to a changeset, possibly keeping all the commit messages in the single commit.