On branching... Wait no, on committing
So, mr. Bennett is causing a ruckus as always, discussing the benefits of Hg over Git.
While I heartily agree that Git branches are sort of a stretch of the implementation to match the metaphor, and I'm sure Hg does it way better (I've used Hg but I use Git much more often.)
However, Git has one feature that just makes it so much better: the staging area.
Coincidentally, the staging area seems to confuse many new users (and Hg users for sure) -- in essence, it's what you're preparing to commit. I don't really care much for Git branches (I just know they're easy to merge, and merges do preserve history).
What it lets you do, and what Git is very good at, is build a commit and refine it before you publish it.
In Subversion I usually make commits that touch files that just don't "deserve" their own commit, and not mention it in the commit message. It could be that I changed a typo in the docstring for a function or something.
It's not like I wouldn't want to commit it by itself, but when there are a couple of such changes in your working directory, with Subversion, you just go "Meh." and commit it all.
With Git, however, you're encouraged to only commit the changes that belong to one commit. The best, most powerful feature in Git, which Hg sadly lacks, is the ability to add parts of a file to a commit. This is, coincidentally, where Subversion is impossible to work with.
So in short, mr. Bennett, committing is what makes me choose Git over Hg.
delicious.comThe record extension (bundled with mercurial but not enabled by default) allows you to commit parts of a file
http://mercurial.selenic.com/wiki/RecordExtension
Here's a +1 for hg record. I use this all the time.
It does come with caveats, though. Without having used git staging, it does sound like it has one up on hg record, the "refine" part. Hg record lets you interactively select for committing chunks of diffs from any modified file.
The negative is that there's no easy way to review which chunks you've picked, nor pause halfway through to do something else, nor change the list of chunks. I end up having to redo a record from the start pretty frequently, so I definitely feel that pain. hg record should have a command to persist the marked-changes-so-far, so I can restart where I left off.
I use Mercurial Queues in exactly the way you use git's staging area (with the added benefit of being able to optionally put the queue in version control -- a repo within a repo). And, as stated in the comments above, you can commit partial changes with Record. Both extensions ship with hg.
git and Mercurial have equal functionality. git may be faster but Mercurial's API doesn't make me want to kill myself.
Seth: Well yeah, I've used the mq extension. It's way more awkward and not really designed for that usecase. You can't easily exclude things from the patch stack to commit, you can just move it up to the next patch or whatever, because that's how it's meant to be used.
As for the API, I don't interface with my VCS very often, don't know about you though.
You said the staging area is "what you're preparing to commit" well Mercurial queues are exactly that. I rarely make a commit without first "refining" (your words) that commit in mq. The process is not the least bit awkward.
If you think mq is only designed and only useful for organizing actual .patch files you are completely missing out on how powerful, how well integrated into hg, and how open-ended it really is.
You can "easily exclude things from the patch stack to commit" by setting guards. You can easily change the order patches are applied by editing the series file. You can easily break out select changes into a new patch with the record extension and qimport. Mercurial queues are every bit the equivalent of git's staging area but with more functionality. Did I mention you can version-control your patches? It's like a staging area with it's own commits and branches! The Mercurial book has a chapter on advanced mq usage.
Lastly, I was talking about the public API -- perhaps interface is a better word. Like Python, Mercurial is ridiculously easy for beginners to learn and has a lovely interface. Also like Python, it quickly scales for advanced usage as user sophistication increases. git, however, is a total mess of giant, cryptic manpages, awful default flags and settings, and non-intuitive concepts. Sure, git is powerful once you learn it but so is Mercurial.
IIRC, hunk selection is possible in the commit dialog of tortoisehg.
Hunk selection and the git index (or staging area) are actually different things. The git index doesn't have to reflect the current state of the files in any way. It's possible to create a commit that looks nothing like your working copy. While this seems extreme, it makes it really easy to split a hunk that has two logical ideas.
"git add -p" actually has an edit option for any hunk you're looking at. You can edit the hunk in a text editor before it gets added to the index.
