I think this point is overlooked all too often. With git, just mashing out code and committing at regular intervals is not using git to its full potential. You'

I think this point is overlooked all too often. With git, just mashing out code and committing at regular intervals is not using git to its full potential. You're supposed to spend time crafting proper commits, consisting of logical, well-separated changes. The staging area and rebase feature make it easy, but it still requires effort that most developers are not used to. Good, logically separate changesets make merging, backporting (cherry-picking), bisecting and reverting much easier. It is worth the trouble. The version history of the git project itself serves as a magnificent example of what a commit history should look like. It's actually possible to read the logs and understand each committed change. (Most of the time)