Git vs. Mercurial
Git
Git is fast, efficient, and not too opinionated. Throw-away branches are a plus (and a minus). With this feature, you can create a feature branch to try something out or work on a new feature in isolation. When you’re done, you can merge the branch back to master/dev/whatever, and delete the branch. In fact, this methodology is prescribed. It’s as if the branch never existed. That can be great, but there are down sides. Knowing the true history of a feature branch has advantages, and you’ll miss out on them if you delete it. If you’re okay with that though, Git branching rocks.
Usage
Git is certainly great, but lacks polish when dealing with its users. If a command has 3 primary uses, and 1 is used 90% of the time, 1 is used 8% of the time, and the last is used 2% of the time, wouldn’t it make sense to make the most used scenario the default for the command? Why is it that so many Git commands require the most used scenarios/options of that command to have so many switches, yet the least used scenarios are the default switch-less version of that command?
Prefer a GUI over the command line? Don’t you ever tell a Git lover that you prefer a GUI for managing your repositories. Just, don’t even bring it up; you’ll get flogged! However, you do have options. GitHub for Windows is excellent software for visualizing your repos in, well in Windows. SourceTree is another great application for working with Git (and Mercurial) in Windows and Mac. But, again, just don’t bring up the fact that you use a GUI for Git. It’s just safer if you keep that to yourself.
Remote Hosting
Sure, you can host a remote repo on your own server, but there are much friendlier options. GitHub is the de facto standard for hosting Git repos and sharing them with others. They support public repos for free, which is great for open-source projects. Bitbucket added support for Git repos after solely supporting Mercurial for quite a while. Now, you can host either type of repo and as an inverse to GitHub, Bitbucket supports private repos for free. Kiln is another great hosting provider for Git (and Mercurial). You can even use Git and Mercurial interchangeably with repos stored on Kiln (which is simply amazing).
Mercurial (Hg)
Mercurial is fast, efficient, and a bit opinionated. Most people will have a difficult time finding real noticeable differences between Git and Mercurial. The absolute biggest difference is branching. Mercurial doesn’t really have a concept of throw-away branches. That is, once you create a branch in your repo, it’s there for keeps. You can get rid of branches with plugins or cloning around the revisions that include the branch. However, having permanent history is actually a strong point for persistent branches in Hg. When you look back through the history, you can actually see where the named branch revisions came from, and that can provide insight into the origins of that code. If you need to work on an experimental branch that may not make its way into the repo, you do have a recommended option; clone the repo and work in the clone for the experiment. If your experiment doesn’t pan out, delete the clone; if you decide to use the code, push it back to the original repo and merge.
Usage
Mercurial is more friendly to non-Linux systems and their users. Yes, I’m vaguely nodding to Windows here. Typically, the commands for Mercurial have sensible defaults, so you’re not constantly hunting down what options you need or constantly typing just to execute a simple command. Installation is also a breeze.
If you prefer a GUI to the command line, there are very nice pieces of free software available. TortoiseHg is a favorite (Windows only). Hailing from the days of TortoiseSVN, this product integrates with Windows Explorer, but now supports a stand-alone client for managing all your repos in one view. Let’s not forget the new kid; SourceTree (by the folks behind Bitbucket) is an excellent Mercurial (and Git!) client that runs on both Windows and Mac. They are catching up with features found in TortoiseHg, but while quickly doing just that, they are also providing unique features (and workflows) to a great application.
Remote Hosting
Again, you can host your own remote repo; Mercurial supports that option. However, Bitbucket offers free hosting for private repos and their system is just outstanding (you can also host Git repos with them). Kiln is another wonderful hosting option for both Mercurial and Git. As mentioned above, you can even use Mercurial and Git interchangeably with repos hosted on Kiln (your team members can use whatever they are comfortable with).
Which is Better?
Really, the appearance of distributed version control systems was a tremendous turning point for developers. Everybody has a full copy of the entire repository as a local copy. You can work offline and sync later. Each developer can act as a makeshift backup of the shared repo. Branching/cloning allows for safe feature trials that can be selectively merged into more stable branches.
Git and Mercurial resolve to the same end; a very efficient history of all your project’s changes over time. It really comes down to your preference of branching strategy and sensible/insensible defaults for the available commands. So, which is better; Git or Mercurial?
Nice try! There’s religion, then there’s politics, and right behind those are programming languages and tools. If you state that one is definitely better than another, you set yourself up for a war. However, we do all have an opinion. Mine is for Mercurial, but that’s just me. I use both extensively on many projects, so I’m not just talking out of turn.
Note: I won’t tell you that your preference is wrong, so do me a favor and don’t tell me that mine is either. Besides, if you’re really nasty about it, I’ll never approve your comment. ;-)