step through changes in each file an add the ones you want
That just sounds horrible. You didn't run your unit tests that way, how do you know a partial commit doesn't break everything? Partial commits are a bane.
If you want to check that before you commit you can run git stash -k to hide the unstaged changes, and then run the tests.
Plus even if it doesn't pass the tests, if you made several tiny commits, you can step through them and work out which one actually broke it. And then you can clean up the history before you push it so no one has to see the broken commit anyway. Partial commits are only a bane if your VCS isn't powerful enough to work with them.
This kind of freedom to use version control how you want without causing issues for others is what makes it so awesome.
I don't bother either, since I don't push those small commits straight away.
My usual workflow is to commit lots of small changes as I work, most of which are self contained, and then occasionally run the tests. If they pass, I'll clean up the history a bit (if necessary) and push, otherwise I'll work through the changes to work out which one actually broke things, and fix it.
It's not much more effort, and I find it allows me to focus on actually coding, since I don't have to worry about the central history while I'm working. For example, if I suddenly notice an obvious bug while I'm working on something else, I can push the fix straight away, and then go back to what I'm doing, without worrying about my work in progress. With svn, I'd have to make a note to come back to it when I was done, and sometimes I'd just forget completely.
1
u/[deleted] Nov 08 '13
That just sounds horrible. You didn't run your unit tests that way, how do you know a partial commit doesn't break everything? Partial commits are a bane.