The differences on commit both have good arguments. hg is going for ease of use and is very much like the non-dvcs's that came before it, like CVS and Subversion where a commit commits all changed files.
git add just adds the file to the index and stages it for commit, this means you can group files logically depending on what has changed, you can even using git add -p have only certain parts of a files modifications be committed and the rest be staged for the next commit. This can be very powerful.
For example, if I did a full refactoring of a class, and fixed a quick bug rather than committing them both at the same time in the patch I can just keep the bug fix and then later commit the re-factored code even if it is in the same file.
Exactly. And if you know that you just want the SVN/HG commit-everything, just add a -a. Pretty intuitive.
Once you get used to having the ability to create arbitrary commits from a huge changeset, you'll find it aggravating when everyone else commits "3 bug fixes to core, swapping out a style sheet, and cleanup in database code" :)
Unfortunately people working with git at work are still doing exactly that. Not sure how to make them stop either, since so far telling them it is wrong hasn't helped ...
git add just adds the file to the index and stages it for commit, this means you can group files logically depending on what has changed, you can even using git add -p have only certain parts of a files modifications be committed and the rest be staged for the next commit. This can be very powerful.
For example, if I did a full refactoring of a class, and fixed a quick bug rather than committing them both at the same time in the patch I can just keep the bug fix and then later commit the re-factored code even if it is in the same file.