A bit of context: I'm in 3rd year of college. students are divided into teams of 4. Almost everyone will be working under windows (except a few like me who are on linux). As part of the school curriculum, we will soon start working on a project for a real client, but me and another team are wondering which way would be best for sharing our code with each other.

I've been working part-time for 3 years and have had plenty of experience using both git and mercurial on different projects, so I don't have any problems using one system or the other. However, none of my teammates have ever used a version control system before. There's also another team who've tried using SVN but have had major problems and would prefer trying out something else, so they've asked for my opinion.

My thoughts : I've heard that mercurial + TortoiseHg has a better integration under windows, but I'm wondering if the concept of anonymous heads might confuse them even If I explain them. On the other hand, I find that git branches are easier for a beginner to understand (clear seperation of work for each programmer) but doesn't work as well under windows.

  • 2
    git has a lot of power enabled by default, but everyone I've talked to say mercurial is simpler to learn, and I am inclined to agree based on my experiences using both. And yes, the mercurial tools are easier to install in Windows vs. their git equivalents. That said, expect to guide people and point them at tutorials for the first week (or more...).
    – wkl
    Oct 28, 2011 at 20:34
  • 1
    Using a DVCS from the beggining is likely to be the simplest way to manage merging contributions from multiple contributors working in parallel. If you find anonymous heads confusing, don't use them (mercurial supports named branches). Oct 28, 2011 at 21:20
  • 2
    Time again to link to this blog post? Git is a Harrier Jump Jet.
    – sbi
    Oct 28, 2011 at 21:32
  • 1
    I never understood why the whole "too hard to learn" matters. Okay, so it takes 20 minutes to learn how to commit and branch and such as opposed to 10... Big deal? Oct 31, 2011 at 20:38
  • 1
    Watch (one of) them go through hginit.com and take actions based on their reactions.
    – chelmertz
    Nov 4, 2011 at 21:27

6 Answers 6


Mercurial, without a doubt.

This is of course, subjective, and vaires from one person to another, but the general opinion is that Mercurial is easier to grok, expecially to someone new to VCS or someone coming from one of the old generation VCS's.

Points in hand:

  1. Mercurial was developed with Windows in mind; Git was ported. No matter what anyone tried to tell me, Git is still a second rate citizen on Windows. Things have certanly improved over the past few years, but you still see a lot of bickering of why something works/or doesn't work on Windows as it did on *nix box. TortoiseHg works very nicely, and Visual Studio implementations are even easier to use without breaking your workflow.

  2. If someone starts the discussion "Git is more powerful after you ...", then he's pretty much saying it all. For 95% of users Mercurial seems more intuitive. Starting from a lack of index, to its more intuitive options (option switches are coherent), to its local numbers for commits instead of SHA1 hashes (who ever thought SHA1 hashes are user friendly??!)

  3. Mercurial's branches are no less powerful than Git's. Post describing some of the differences. Going back to some previous revision is as simple as "update old-revision". Starting from there; just do a new commit. Named branches are also available if one wishes to use them.

Now, I know that all these are details, and they can be learned and everything, but the thing is ... these things add up. And in the end, one seems simpler and more intuitive than another. And version control system should not be something one spends time learning - you're there to learn programming and then to programm; VCS is a tool.

Just to note; I use Git and Mercurial daily. Don't have trouble using either one of them. But when someone asks me for a recommendation, I always recommend Mercurial. Still remember, when it first came into my hands, it felt very intuitive. In my experience, Mercurial just produces less WTF/minute than Git.

  • 4
    + for "VCS is a tool". I hadn't considered the "small things" as a factor, but it's true that when you add up small problems here and there they can become a real nuisance. Oct 28, 2011 at 21:53
  • 8
    "Version control system should not be something one spends time learning." This is a load of crap. You should always spend time learning your tools. You spend time learning your compiler; but the VCS is just as critical a tool for your programming as your compiler is.
    – JesperE
    Oct 29, 2011 at 7:31
  • 9
    +1. Especially the 'second class citizen on windows' argument is absolutely important in this situation.
    – tdammers
    Oct 29, 2011 at 8:23
  • +1 for "WTF(s)/minute" (osnews.com/story/19266/WTFs_m). These kids gotta learn the skillz :-) Oct 31, 2011 at 10:50
  • 1
    @Mark that's just a result of a terminology difference... A branch in Git is really just a name. Oct 31, 2011 at 20:43

I've found that the TortoiseHg UI is a great experience on Windows. When experimenting with Git in the past, I ended up going to the command line instead. To your average user, a good UI is much more approachable than a command line. So, I'd suggest using Mercurial. (It includes a nice branch graph in the workbench window, too. It should clear up any of the basic branching difficulties.)

Once they understand things from the UI perspective, they may end up going to the command line to script or do manual operations - but they don't need to.

  • Being a "console junkie" myself i've never used the Tortoise{Svn,Git,Hg} apps before so I didn't know TortoiseHg had a branch graph. I'll have to go check that out Oct 28, 2011 at 21:27

If you're interested in a third option, I'd suggest fossil. I find the ability to throw up a temp web server to share code works great in small projects. Fossil is just an executable, so you could put it and your source into a thumb drive, and use it from any university computer.

Use fossil ui to start a temp web server wherever you are to have your fellow students sync up with you. It also gives you a ticket system, wiki, and easy to use web interface for changing branches and tagging commits.

Just make sure they read the quickstart guide, and/or the book. Finally, there is a project called winFossil to give them a friendlier user interface than the web ui.

  • I've heard good things about fossil, but unfortunately I don't have that much time to get familiar with a new DVCS. I prefer using something i'm used to (if possible) since I already know how to work around the most common pitfalls. But thanks for the suggestion, I'll definitely look into it once I have the time. Oct 28, 2011 at 21:22
  • +1; fossil is little known but it's so easy to work and so self-contained (dvsc+wiki+tickets+webserver) that it is a real alternative to the whole of trac or even github.
    – Javier
    Oct 29, 2011 at 21:02
  • But fossil will not look as good on the students CV as git or hg, as very few poeple have hard of it.
    – Ian
    Nov 1, 2011 at 12:38
  • Mercurial has built in hg serve functionality too. It misses a bug tracker and wiki of course. But then theres also bitbucket.com Nov 19, 2011 at 21:49

Given that the teams are new to version control, and many are using Windows, I'd recommend mercurial over git.

The conceptual model of version control used by git and mercurial are very similar, so once you've mastered one, it's easy to pick up the other (and for similar reasons, it is quite easy to convert a repository from one to the other). This means its not a big deal if you change your mind later.

In my opinion, mercurial is easier for new users to learn. It makes simple things easy, and dangerous ones hard. Git makes dangerous operations easy (easy to do, not necessarily easy to do correctly!).

The TortoiseHg interface for Winodows is very nice too, and is another argument in favour of using mercurial.


My personal preference is for git.

However, as some people will be using windows and the superb hginit tutorial exists, I'd recommend teaching them mercurial.

  • +1 for mentioning hginit. Although, Pro Git is pretty good, too. Oct 29, 2011 at 16:48
  • @TamásSzelei, Thanks, I hadn't seen Pro Git before. Oct 29, 2011 at 17:36

As many people have suggested, Mercurial via TortoiseHg has a very low barrier to entry.

For those on Windows it's a single installer rather than two installers (and a whole load of stuff they might not want to learn about) and the THg user interface is much more polished than TortoiseGit+Msysgit.

Anonymous heads

If you think they would be confused by anonymous heads, then don't encourage their use. Most hg books take a balanced approach and teach both topological and named branches, and let the reader determine which is most appropriate for their use.

Named branches

One thing I really miss in git is hg's named branches, so that's one option. git branches are fine while you are working on them, but once you've merged that work into another branch, you lose much of the context for those changes.

In hg you could create a branch called Jira#1234 and always be able to find all of the revisions associated with that fix. In git, once your branch is merged in and the ref deleted, you have to infer which revisions were part of the fix from the topology of the revision tree. Even if you don't delete the ref, you still only know the last commit on that branch, not which of it's ancestors were part of that chain of commits.


Alternatively, if you don't want to use named branches, but want a git style workflow with your anonymous branches, then you can use bookmarks instead.

This could be the best of both worlds - they get to learn a git workflow, but get to use the simpler hg commands.

Index/Cache/Staging area

Personally, I think students are far more likely to be confused by the git's index/cache/staging area than by hg's anonymous heads. I much prefer hg making this advanced functionality optional on the command line, over the way git assumes you always want/need to use it.

I also think that the staging area encourages commits which haven't been tested or even compiled. Since many of the places I've worked have had a don't commit if it doesn't compile rule, I would much rather shelve/stash changes I don't want right now, re-run unit tests and commit a version that I know compiles.

When you later come to track down a bug using hg bisect or git bisect, you will thank yourself that you can test all of the revisions, not just the ones that compile.

  • You don't have to delete the git branch after you are done; it is only custom. Also -1 for misinterpreting uses of the index - you don't use it for staging bad commits, you use it for staging partial steps of a larger series of commits. Usually this happens during a rebase when you are clearing up your history. Oct 31, 2011 at 20:45
  • @mathepic - If you don't delete branch names, and push all of your local 'fix' branches up to remote then you are going to end up with a huge number of refs, just like you end up with a plethora of old branches in svn. In hg these branch names are always topologically local, so you only see them if you look for them.
    – Mark Booth
    Nov 1, 2011 at 12:03
  • @mathepic - As for your -1, I think you are misinterpreting what I'm saying. I can't imagine why anyone would intentionally make a bad commit, but with git it is easy to do it by accident. If you forget that file c implements a modified interface in file i and accidentally commit the i without c then if someone pulls in your changes before you've got around to committing c their compile will fail. If you use the stash/compile/commit workflow instead, this mistake is simply not going to happen as your own build will break first. I've tried to make my answer clearer though.
    – Mark Booth
    Nov 1, 2011 at 12:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.