cheap local branching: there's bookmarks, there's named branches, and there is mq. one of the cool things about mq is that the patch queues can themselves be an hg repo. so if you're using a patch queue like you would the git index, you can 'push' that state somewhere else as way of backup. can one do that with the git-index? (if you rsync your tree, get ready to rsync huge pack files everytime they change .. see below)
everything is local: this is the exact same thing on git and hg. hg incoming means check another repo for incoming changesets. ergo it needs to contact that repo which need not be remote.
git is fast: we have our source tree in hg and git. ~10k files plus binary stuff. no one notices any difference. on windows, hg is faster.
git is small: maybe so. but you have to remember, (and perhaps understand) about git-repack and friends. hg, is like a self-cleaning oven in this regard.
staging area: if one needs such a thing, there are mercurial queues. if you dont, it's not in your way.
distributed: yes. hg is distributed. that's why it has commands like incoming.
any workflow: same thing in both.
github: http://www.bitbucket.org/
easy to learn: git is easier to learn than mercurial?
ok, now here's what i don't like about git:
storage: it's annoying to have to setup git-repacks jobs for each repo, but that's fine. the real killer for us is that it kills our incremental backup strategy. every time you repack you create a new pack file (in our case huge) and you have to back it up again. in mercurial you can back up the files that changed.
bundles: git now has them but they started in mercurial. i'm putting this down because there seems to be this perception that all the cool stuff happens first in git.
index: fine after you're a pro, but we have had accidents. learning curve is a bit strict with git.
documentation: better in hg. much better actually.
git has gone through a lot of interface changes. is cogito still in use? and then they broke renaming at one point. i'm sure these things are fixed, but we've had no such issues in hg thus far.
in the end they both rock, but i prefer hg.
Very true. Mercurial's design puts most of its non-core functionality into extensions (which are easy to ignore if you don't need them), and has a clean setup for adding new extensions. How does git handle that? I haven't looked into the git source lately.
And regarding "incoming", the article says that git has a separate command (fetch) for caching server data, i.e. if there are incoming patches, when connections are available. (According to git-fetch(1), fetch looks more like pull without updating/merging locally. Unless I'm misunderstanding things, the comparison to hg's incoming is probably a bit of a stretch.)
It took me literally 3.5 minutes to get Git setup using the OSX install package and fixing my .profile to include the new path. I'm very impressed.
Now if only Github had a trial membership with a Private repo...
Of course, that's just my opinion. :-) You may not even be targeting students anyway.
Git just seems overly complex for all but the most sophisticated workflows. I could be wrong, but that has been my experience.