Update 2011-10-07: SourceTree is good enough that it gradually displaced all other git clients. Developer Steve Streeting was productive and responsive, churning out stable improvements. This week, Atlassian (maker of JIRA and other stuff) announced that they had acquired SourceTree (and Steve Streeting). That is probably good news, because it means more resources behind ST. Even better, SourceTree is now free "for a limited time". So now there is really no reason not to get the best git client for Mac.

I used Mercurial for three years, but started switching to Git about a year ago. I now grudgingly recommend Git to anyone who intends to be a full-time programmer. Git's interface is bad in many ways, which is the main complaint about it, and it's a legitimate one. It's just an interface, though, and this is a tool you're going to use all day, every day, in a wide variety of situations.

Here are all of the ways that Mercurial has harmed me, or that I've seen it harm others, and the ways in which Git does good where Mercurial does evil:

A simple workflow diagram on how to use Mercurial.

One of the best things about Mercurial is that branching actually works really well. Branching works well because merging works well, and merging works because Mercurial, and other DVCSs, track history in a new way. The result is a more sophisticated approach to merging, and the ability to make merges a part of the history. That means that if something goes wrong, you can just roll back and try the merge again.

There are generally two reasons to create branches:

You want to work on a feature, but it is going to destabilize the code enough that you don't want to impact other developers working in your "trunk" repository.
You want to create a long-running branch for yourself or another developer (workspace). The workspace allows you to work without disrupting anything that is going on in the "trunk" repository. This also facilitates the "review everything before it goes into trunk" code-review process.
Kiln supports both of these use cases out of the box. With a few clicks, you can be using a workflow that actually matches the way that you've always wanted to work with your code and co-workers. If you're curious, you can check out the complete how-to guide.

A while ago Jeff and I had Eric Sink on the Stack Overflow Podcast, and we were yammering on about version control, especially the trendy new distributed version control systems, like Mercurial and Git.

In that podcast, I said, “To me, the fact that they make branching and merging easier just means that your coworkers are more likely to branch and merge, and you’re more likely to be confused.”


This is what Taco looks like now
Well, you know, that podcast is not prepared carefully in advance; it’s just a couple of people shooting the breeze. So what usually happens is that we says things that are, to use the technical term, wrong. Usually they are wrong either in details or in spirit, or in details and in spirit, but this time, I was just plain wrong. Like strawberry pizza. Or jalapeño bagels. WRONG.

Mercurial is a modern, open source, distributed version control system, and a compelling upgrade from older systems like Subversion. In this user-friendly, six-part tutorial, Joel Spolsky teaches you the key concepts.

Something that isn’t entirely clear from the use of Mercurial, is how to un-add a file you accidentally added, before you commit.

It's a land rush of revision control, I tell ya! Among the stable of eager candidates for best-loved DVCS, Git and Mercurial seem to be the two tools capturing the most programmer heart-share for now.

Git is admired because Linus Torvalds wrote it, but Mercurial is better because he didn't.