I’ve been interested in DVCS for a while; having done my fair share of branch management, something which makes that process easier and more transparent is definitely very attractive. I particularly like the way a DVCS makes it easier for people to collaborate in pockets of their own, away from the centralised environment, and track other repositories and keep their local mods up to date more easily – public-branch-on-demand if you will. However, I’m yet to be convinced by Git for everyday use. As noted, I love the idea, but Git comes across as – and this is an ironic thing for me to say – excessively geeky. At one time I might have believed there was no such thing as a plethora of geekery, but I like to think I’m a more rounded individual now 
Don’t get me wrong, I’m sure Git is technically excellent. But a number of things about it remind me of the somewhat stubborn purisms of ‘old Linux’, such as:
- The documentation is hugely daunting. Whenever anyone tried to convince me why Git is amazing, they point me at documentation that just makes me not want to touch it for anything important. The impression I get is akin to some Linux forums: – this thing is powerful, but it gives you plenty of rope to if not hang yourself, then to tie yourself in knots if you don’t know what you’re doing.
- It requires a Unix back end, to the extent that you have to run it under Cygwin on Windows, and its rigid filesystem requirements mean it won’t work on FAT or Windows network drives. I get the impression there’s something rather aloof about the fact that the core team don’t consider it an issue that Git won’t run on native Windows environments. There are external projects working on that, but the fact that it’s not core is a concern, since I prefer all my 3 platforms to be supported equally.
- The UIs still don’t seem very user-friendly, and most responses I see to the question of why that is boil down to “Git is too powerful to be captured in a GUI”. Sorry, but I don’t buy that – no system is too complex to be captured in a user-friendly tool, it just takes the will to do it, and like ‘old Linux’, there seems to be little will to make Git more approachable.
So, I’ve never had great vibes from Git, despite it’s doubtless technical merits. So, I decided to check out Mercurial instead – from what I read, Git is the fashionable DVCS that all the cool kids want to be seen using, but when it comes down to it Mercurial does exactly the same thing – except that it has native support for all platforms out of the box and TortoiseHg is looking pretty mature. I also read that it handles binary files better than Git too, since it does binary diffs everywhere. The documentation seemed much more approachable too, so I figured I’d have a play.
My first impressions are incredibly positive. The most impressive thing of all is that I imported a (relatively small- about 100 revisions) Subversion repository, with all the history intact, about 5 minutes after installing it, and was bouncing that across Linux and Windows immediately afterwards (haven’t tried OS X yet). TortoiseHg is instantly familiar, and despite the fact that the concepts are the same as Git, the presence of some familiarity, together with some distinctly less intimidating documentation, has me feeling far happier than the times I’ve dipped into the Git docs. Mercurial’s approachability is a positive contrast to Git’s Unix-purist, RTFM style I think. I know which I prefer so far.
August 5th, 2009 at 12:02 am
Yes it is a shame that git is lacking in the windows and GUI aspects, and as such I’d certainly say that mercurial sounds like a good choice when you’re looking to support multiple platforms, or use a GUI. That said I don’t entirely agree with the documentation thing. The git tutorial which ships with git ( http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html ) seems to me to be incredibly easy to read and understand. More information on specific aspects can be found in the various other help files relating to each command, or on the internet in places like this. http://github.com/guides/home ( I know that’s really not documentation but it’s there )
In the end though, Git, Mercurial, Bazaar, etc all do pretty much the same thing, with the latter usually toning down a couple of steps from git.
Oh and http://whygitisbetterthanx.com/
August 5th, 2009 at 12:19 am
Hey steve,
My 2 cents on git:
I’ve been using git on windows with msysGit and I am a very happy user, without having to use Cygwin. And I believe there’s also a tortoisegit – but I haven’t tried it.
For documentation, I just use the scripts on this single page. They have been enough for me; but I guess your branching needs are far superior.
Glad to hear that you are happy with Mercurial, though.
August 5th, 2009 at 1:21 am
I always point people here for documentation: http://gitready.com/. Forget about the official docs.
August 5th, 2009 at 3:46 am
Couldn’t agree more with regards to git. What kills the usability for me is their bizarre decision to choose weird or new naming conventions for just about every operation. Mercurial on the other hand reuses the command naming scheme *where appropriate* from CVS and SVN. Mercurial feels like a natural progression usage-wise from the 2 main RC systems out there. I almost believe that git went out of its way to be as obtuse as possible on purpose, since there is NO reason that it needs to be so. Also, it felt like every git command required 2-3 times as many keystrokes as the equivalent mercurial command (including a bunch more non-alpha-numeric ones to boot). It very much reminds me of the Debian and Slackware mentality versus that of Ubuntu or Mandriva, except represented by git and mercurial respectively. That my wordy way of saying that I can’t stand git either and have recently fallen in love with mercurial as well.
August 5th, 2009 at 9:14 am
I’m in the same position – choosing between git and hg. Mainly because I’m starting a new project and want to see what the fuss is about with DVCS.
I decided to try git, using msysGit and TortoiseGit, and so far it’s been simple enough – it looks a lot like TortoiseSVN.
I’m on Windows though, so I don’t know about OSX.
August 5th, 2009 at 10:05 am
Yes, I’ve seen the MSYS version – that’s what I was referring to when I mentioned external projects. It’s still not ‘native’ though, it’s just a more minimal Unix simulator – that doesn’t address my concern about first-party platform support.
It does concern me that the most common suggestions regarding addressing my Git concerns involve bypassing the core project. Don’t read the core docs, read someone elses. Don’t use the core Git binaries on Windows, use an external port. Don’t use the Git commands, use wrapper scripts. If Git doesn’t care enough about these issues to address it in the core, what does that say? It suggests my needs and the priorities of Git are not aligned. This might sound pedantic, but when it comes to critical components of my development environment, whether the ethos and design principles of the tools I’m using fit with the way I want to work is more important than whether they can be shoehorned into working. So far, Mercurial seems to align better with the way I want to work, right in the core project.
I do think that people make too many excuses for Git being unfriendly to the uninitiated and to non-Unix platforms. It’s clear it was designed from a purist standpoint – no doubt because Linus obviously has strong views about what platforms are ‘best’ – and to be honest, I don’t like that stance very much.
As I said before, and it seems Eric agrees, Git seems to have many hallmarks of ‘old Linux’, where everything else is ‘obviously’ inferior and not worth considering, and you somehow have to earn your right to use it. Mercurial is a bit more pragmatic, which is why I’m liking it better, so far. Once I’ve learned a bit more, I will probably try Git again to have a more informed comparison, but Mercurial is more pleasant to learn on.
whygitisbetterthanx.com is obviously written from a Git fan’s perspective, promoting all the positives and ignoring the negatives – such as the fact that Mercurial stores binary diffs more efficiently, and the Git staging area is promoted as a universal positive when it has dangers too (you can screw it up if you forget to re-add or use -a on the commit line). You’re better reading analyses from people who have no allegiance one way or another. I liked this article: http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/
August 5th, 2009 at 10:39 am
I still disagree with the usability angle, git is one of the most user-friendly console applications I’ve ever used, it’s often suggesting commands, git help always seems to do the trick. That said I’ve been using git exclusively on linux with the command line, which I am comfortable with.
I see git as being unix-like in that it provides one with all the tools and all the flexibility, although I don’t believe this hinders ease of learning. It’s powerful enough to support literally any workflow you one could contrive, while still maintaining simplicity. Wrapping git commands with helper scripts seems really silly, I don’t see how you could make it any simpler and the only possible advantage I see could be integration with existing tools expecting SVN. I suppose I’d blame the windows issues on typical open source selfishness, scratching ones own itches.
Once again, I’ve not used git at all on windows, and it certainly seems to need some work. Nor have I used any GUI tools, which also seems to need some work. I do however very much like the power and flexibility that git provides ( and once again I really don’t think it sacrifices usability in this area, hell, I find git easier to use than svn – mainly because svn is ever crashing and generally being a pain in the ass.
)
I’d certainly take a serious look at Mercurial or Bazaar for any serious cross platform anything I was hosting however.
August 5th, 2009 at 11:03 am
Same thing here, I will be moving all my SVN stuff to Hg soon. The import is miraculous. The only thing that is keeping me from moving would be having to reconfigure my Trac to use it (which IS possible, but takes some time).
August 5th, 2009 at 1:46 pm
@galaktor: oo, information on Trac migration / integration would be very welcome, please post it when you got it
August 5th, 2009 at 2:36 pm
Hm, I find it interesting that you describe TortoiseHg as “mature.” We’ve been using Mercurial for a school project from September to December of last year and while I enjoyed Mercurial and it served us well, the last thing I’d describe TortiseHg would be mature. But maybe the dev team did wonders to the app since version 0.4 we were using …
August 5th, 2009 at 3:10 pm
You may like Git Extensions http://code.google.com/p/gitextensions/ . It’s a Visual Studio plugin for git. You have to install mysys and this to have it work.
August 5th, 2009 at 3:23 pm
Welcome to a new and wonderful world of distributed versioning !
About Trac: Well.. I had a hard, hard time tweaking and fighting it to do what I wanted it to do. You have to make use of Trac Hacks to enable a lot of features which Redmine already has out of the box. And the latest version is over two years old.
I only had to do a rake redmine:migrate_from_trac and all tickets and users were imported. And I had all the features and ease of use I wanted in the first place.
Redmine supports all major source control systems ‘out of the proverbial box’. And with a non-clunky interface too. What more do you want?
I spent over a week setting up Trac to a barely usable state, and only one day on Redmine..
Well, well
August 5th, 2009 at 3:30 pm
@marco1475: I’m using TortoiseHg 0.8.1 (and TortoiseGit 0.8.1 – spooky version alignment) and so far it’s been very solid. It’s nice that it just installs & goes on Windows, wheras TortoiseGit bitches about missing msysgit (which you have to install separately, shame it’s only mentioned at the bottom of the page after a zillion screenshots) – quite why they don’t package the command-line tools with it like all the other Tortoise* tools do I don’t know.
@jacmoe: I’ve only used Redmine once on a customer project, and my only issue with it is that it seemed way slower than Trac. I haven’t tried it on a local machine though, I’ll have to give it a go.
August 5th, 2009 at 4:30 pm
So once again Easy to use > then technicaly superior.
Now I see why Linux is no Win XP and Win XP is no MacOSX
August 5th, 2009 at 5:20 pm
@kinjalkishor – That assumes that obtuseness = technical superiority. Ease of use is a critical component of the technical merits of a piece of software. For me mercurial delivers as a whole on features, functionality, speed, design, and ease of use. For many of their users some of the unique functionality of git makes it better software for their particular use, but in my case it offers nothing that I cannot already get from mercurial in a better designed package. Dismissing usability is a critical failure often perpetrated by the open source community and IMO git is simply the latest example of that. Having to fight against the syntax required by a piece of software or having to wrap it with custom scripts so that it is more usable (as often suggested for git) is unnecessary and harmful to productivity. Things that waste my time, especially when there’s no real reason for it to be the case, annoy me to no end.
August 5th, 2009 at 5:46 pm
Yeah, my experience so far leads me to believe that Git is more popular because:
a) It has the ‘brand recognition’ and kudos of Linus behind it
b) For a while it had some significant operational advantages over alternative DVCSs
My impression now is that the DVCS environment is normalising, and that there aren’t that many significant differences anymore for the vast majority of people, as Mercurial borrows features from Git and vice-versa. Therefore choosing between Mercurial or Git comes down to little things.
So far, forgetting documentation style for a moment, I prefer Mercurial because:
a) I can point Mercurial at a Samba drive or USB stick and it functions perfectly happily. Git doesn’t, it fails because it considers those to be ‘inferior’ filesystems and refuses to work. In practice, it’s really nice for things to just work the same everywhere. Sure you can generate patches and blobs that can be stored on a USB stick, but for example I find it really useful to just push changes wherever I want, however I want, so long as I can see the destination *somewhere* – Git won’t let me do that.
b) Mercurial doesn’t overload me with information so much. Even TortoiseGit tends to tell me more than I really want to know and give me options I don’t understand on a regular basis. Mercurial mostly just does what I expect.
c) I prefer Mercurial’s branching style – it just seems more intuitive to me
I’m going to continue playing anyway.
August 6th, 2009 at 12:58 am
Maybe it’s because I don’t use any advanced features of git but it seems pretty simple to me. I’m using bazaar for my own code at the moment though because it’s stored on launchpad.
No experience with Mercurial but they all seem to have the exact same features to me.
August 6th, 2009 at 10:02 am
@steve
I have not done it yet, but it seems to be trivial to integrate a Trac repo into the TracBrowser. Check out this link:
http://trac.edgewall.org/wiki/TracMercurial
Let us know if it works out, since this is coming my way soon
August 6th, 2009 at 10:03 am
*D’OH*
There’s a typo in there…it should be “Mercurial repo” instead of “Trac repo”…
August 6th, 2009 at 10:06 am
@Andrew: I guess that’s my question to all the other people who say Git is easy too – are you actually using it to manage a multi-branch project with many contributors, or are you using it just as an individual? There’s a big difference.
In the end for me it’s not about whether it’s ok for just me, it’s whether I can run 2-5 ‘official’ branches and manage contributions from lots of other people efficiently and without making mistakes, without missing things that need merging, without pulling breaking changes into a stable branch, etc – all without having to make manual decisions all the time because no one person has perfect knowledge of the entire repository, because there are lots of people involved. There’s always lots of talk about how Git lets you fix problems, since it has effectively a mutable history (that scares me too) but I’d prefer a system that naturally leads to less errors in the first place through being intuitive in these scenarios. Complexity usually means more mistakes.
I know Git is used for big projects too, but often it’s the geekier ones that *really* use it fully
I want repeatable, easy to understand procedures that a ‘normal’ development team can use efficiently to manage a multi-branch DVCS without having to be experts in the tool itself. I’ve already had to mop up after screw-ups in branch management in CVS and SVN over my time as lead on multiple projects (open source and otherwise), and those are much simpler systems!
August 6th, 2009 at 10:59 am
@Steve:
I think those things are the least of your worries. Git goes a long way to make sure you don’t break things I don’t know what you consider “geekier”, there’s an awful lot of ruby / rails stuff using git and I certainly wouldn’t put web developers into the “geekier” category, I assume you’re talking about the linux kernel and other related projects.
All the gnome projects use git now days I believe, and there has certainly got to be some “normal” developers in there.
In the end though it comes down to what you’re comfortable with. I’d probably suggest trying them both out with smaller projects, or even mirroring the Ogre svn with them and working off that for a while. In the end any DVCS will be better than SVN.
http://github.com/rails/rails/network Branches and contributions.
August 6th, 2009 at 11:03 am
http://github.com/radiant/radiant/network Actually this is a better example, bit more compact. It’s a rather cool visualization actually.
August 6th, 2009 at 11:15 am
Thanks for the examples, although they’re still fairly simple
Yeah, I was talking about the likes of the Linux kernel – my projects tend to be in the middle – complex enough that simple manual ad-hoc management doesn’t work (e.g. keeping manual records of what is awaiting merging like some projects do), and I need to do 2-way merges on occasion etc, but not at the extent where I’ll be extensively using those features every day, so I want something I can just pick up & use to resolve the complexities quickly, repeatedly, and easily without mistakes, without having to refer to the manual all the time.
When I get more time I’m going to play with some engineered examples of things I normally come across and see how easy Mercurial and Git make it. So far Mercurial is winning on what I’ve tried so far, as discussed in the 3 points above.
August 6th, 2009 at 11:39 am
I presume you’ve seen this, but here it is anyway. http://code.google.com/p/support/wiki/DVCSAnalysis The comments are also interesting.
August 6th, 2009 at 1:24 pm
I hadn’t seen that actually, thanks. I agree with the article so far.
In fact, I wasn’t aware that Google Code had picked Mercurial over Git, that’s pretty interesting. It appears they did so for much the same reasons I’m currently leaning that way.
August 6th, 2009 at 1:45 pm
Looks like Python chose Mercurial too: http://www.python.org/dev/peps/pep-0374/
Funnily enough, all the ’serious’ analyses that I’ve come across so far where a single DVCS choice has been made, have come down on the side of Mercurial – never by much, but there have been the typical small things that have tipped it like Windows support and ease of re-training from CVS/SVN. I haven’t yet seen what I would consider a serious unbiased analysis that’s come down on the Git side yet. Anyone have any of those? All the pro-Git stuff I’ve read so far has been written by people with vested interests (like GitHub), or people who don’t care about Windows, or individal developers who like it because it’s cool. Are there any level-headed comparisons out there that felt Git was best that I should be reading?
August 6th, 2009 at 5:28 pm
[...] so I’ve posted my initial feelings about tinkering with Mercurial and Git, and that seems to have generated some interest. It’s [...]
August 6th, 2009 at 11:14 pm
I searched the Qt blog for ‘mercurial’ because I was curious why they chose Git, and this is what I found:
http://is.gd/25B2b
If we remove their specific criteria, like easier migration from Perforce and in-house knowledge, it looks like Mercurial is the overall winner.
But read it yourself.
August 7th, 2009 at 10:28 am
Thanks – a little light on detail that one though
It’s hard to know precisely what the decision points were.
Here’s my other non-scientific observation: of the projects that choose Git, the majority of them seem to be Linux-focussed (Qt is one of the exceptions, but that’s the trend I’m seeing: http://git.or.cz/gitwiki/GitProjects). It makes sense given that Git runs best on Linux, and that it regards Windows and non-Unix filesystems as second-class citizens that either need (slower) wrappers (Cygwin/MSYS) or won’t work at all (FAT). That, along with the obscurity of some of the commands is what’s concerning me about using Git for my projects right now.
August 8th, 2009 at 2:53 pm
Found a more rational and detailed pro-Git post: http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
Interestingly I’m having less success on the Mac with Mercurial, the free & open source GUIs really aren’t very good so far – TortoiseHG hasn’t been ported completely yet, Murky and MacMercurial cover too small a slice of the functionality to be a primary tool. In contrast GitX seems quite rich. I’m still keeping an open mind, let’s see how this plays out in the round.
October 25th, 2009 at 8:57 pm
[...] started my DVCS evaluation very pro-Mercurial and very anti-Git. While working through my detailed use cases, a process which [...]