Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as off-topic by gnat, Bart van Ingen Schenau, MichaelT, GlenH7, Kilian Foth Sep 12 at 9:59

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, Bart van Ingen Schenau, MichaelT, GlenH7, Kilian Foth
If this question can be reworded to fit the rules in the help center, please edit the question.

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...). –  birryree Oct 28 '11 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). –  Stephen C. Steel Oct 28 '11 at 21:20
2  
Time again to link to this blog post? Git is a Harrier Jump Jet. –  sbi Oct 28 '11 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? –  alternative Oct 31 '11 at 20:38
1  
Watch (one of) them go through hginit.com and take actions based on their reactions. –  chelmertz Nov 4 '11 at 21:27

6 Answers 6

up vote 48 down vote accepted

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.

share|improve this answer
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. –  Gregory Eric Sanderson Oct 28 '11 at 21:53
4  
"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 '11 at 7:31
9  
+1. Especially the 'second class citizen on windows' argument is absolutely important in this situation. –  tdammers Oct 29 '11 at 8:23
    
+1 for "WTF(s)/minute" (osnews.com/story/19266/WTFs_m). These kids gotta learn the skillz :-) –  Ross Patterson Oct 31 '11 at 10:50
    
IMHO Mercurial branches are more powerful and flexible than git branches. Named branches are a significant advantage for some workflows, bookmarks allow you to replicate git workflows and automatic creation of topological (anonymous) heads means you never have to explicitly name branches if you don't want to. –  Mark Booth Oct 31 '11 at 17:16

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.

share|improve this answer
    
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 –  Gregory Eric Sanderson Oct 28 '11 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.

share|improve this answer
    
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. –  Gregory Eric Sanderson Oct 28 '11 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 '11 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 '11 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 –  Johannes Rudolph Nov 19 '11 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.

share|improve this answer

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.

share|improve this answer
    
+1 for mentioning hginit. Although, Pro Git is pretty good, too. –  Tamás Szelei Oct 29 '11 at 16:48
    
@TamásSzelei, Thanks, I hadn't seen Pro Git before. –  dan_waterworth Oct 29 '11 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.

Bookmarks

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.

share|improve this answer
    
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. –  alternative Oct 31 '11 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 '11 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 '11 at 12:04

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