| Git requires that you do a "git add" before doing a "git commit". Mercurial assumes that you want to add all the changed files in your repo (or you can list the files needed in a commit). This is one of the features of git I most appreciated when I started using it (my first VCS was Mercurial). I get distracted easily. While I'm rooting through the code base trying to do something, I'll notice something else to fix. And something else. And something else. By the time I've finished whatever I was trying to do in the first place, I've got 5 or 6 different things I've actually done. In git, it's trivial to split these up - `git add` separate files, or `git add -p` when you only want to stage some of the changes in a file. This leads to cleaner commits. I've heard people decry this, saying that you should be testing each individual state of your codebase. git being the powerful sonuvabitch it is, you can do that: * `git stash --keep-index` will store away all of your modifications, other than the ones you're getting ready to commit. Run your tests, commit, `git stash pop`.
* Checking out different revisions and running tests isn't a bad option, either, whether you use `git bisect` or do it manually. With the amazing power of `git rebase -i`[0], you can easily fix any little issues without disrupting other commits. [0]: http://schacon.github.com/history.html You will change their SHA1 sums, so they'll become different commits. This isn't a problem, though, if you haven't pushed them up to a shared repository. |