Git v Mercurial

[ShandyDrinker]

I'd go with the majority of reviews on here so far. If you're working primarily in a Windows environment I think Mercurial is much more straightforward than Git simply because, as another post mentioned, it all works from the one installer for TortoiseHg.

The big advantage both have over SVN is as everyone mentions, the ability to have local commits which can then be pushed up to a more centralised repository if required.

Although I still love SVN because it is so ubiquitous and easy to find information about, it can be quite cumbersome to work with especially if the central repository is based in another part of the world and you have to constantly access it to update and commit.

In reality this is more a discussion about centralised versus distributed revision control systems... and what ecosystem support you want from your IDE, bug tracking, continuous integration systems and so on...

[VectraMan]

Bump.

PermieCo finally made the jump to Mercurial after talking about it for 6 months. It's all quite interesting; the local repository way of working certainly is a big improvement, if slightly confusing at times. What's not so good is TortoiseHg, which I assumed was just going to be TortoiseSVN built on a different base. But no - it's the worst kind of Open Source afterthought GUI you could imagine, and like all GUIs that work by running a command line program, it's extremely clunky, you don't get useful progress, you don't get useful errors, etc. etc.

And errors generally are a problem. Pretty soon you'll do a "push" and you get some terrifying message about creating two heads. What it actually means is "your repository is out of date", so why can't it say that?

As a comparison, I've been playing with GIT and TortoiseGIT (which has at least been copied from TortoiseSVN with the same style dialogs). They work in an identical way as far as I've seen, but Git does generally seem to do things in one step whereas Hg needs two. And the Git error messages are generally less unfriendly.

However, minus several marks for Git for ease of setup. For Hg you just download TortoiseHg and it works, but downloading TortoiseGit doesn't just work, you need to go download GitW, which then, get this, compiles itself. Why can't these people understand that normal people want to run a normal install program and just start using the software?

So my review: they do the same thing, but Git wins by having less bad GUI tools, assuming you're a human and want to use a GUI that is. The only plus point of Hg is that it has a simple webserver to share changes, but small teams can probably use file shareing to easily acheive the same thing with Git.

But having used TortoiseSVN as my main method of source control for years now, the user experience is very poor for both. It's a shame, but these are bad examples of open source: tools written by über-geeks for über-geeks.

[Sysman]

The difference is if circumstances force you to move away from the traditional model - think you have to commit on a plane or anywhere offline - I couldn't get any signal (not even plain GPS, nor travelodge's own overpriced wifi) at Stansted Travelodge so not an uncommon scenario.

With mercurial I just kept commiting to a local repo and merged the history of changes next week.

With SVN it would be an untracked big lump of changes.

The ability to work off line is the differentiator for me. On the git vs Mercurial question, my website ISP has just done an upgrade and git is there, Mercurial not, so it's a bit of a no brainer here (it was just svn before).

[xchaotic]

The question just like others have mentioned should be centralised VCS vs distributed one so SVN vs Mercurial/Git/etc.

The thing is if you are starting a new project you should start with a DVCS.
You can still use it like a plain old SVN - just designate one repository to be the 'central' one and the commands or shells (tortoise) are pretty much the same.

The difference is if circumstances force you to move away from the traditional model - think you have to commit on a plane or anywhere offline - I couldn't get any signal (not even plain GPS, nor travelodge's own overpriced wifi) at Stansted Travelodge so not an uncommon scenario.
With mercurial I just kept commiting to a local repo and merged the history of changes next week.
With SVN it would be an untracked big lump of changes.

[VectraMan]

Despite people getting all stiff over DVCS, I'm still quite happy with SVN though.

WHS. One day I'll get round to having a look at both git and mercurial, and they both now have Tortoise clients.

[d000hg]

Despite people getting all stiff over DVCS, I'm still quite happy with SVN though.

[OwlHoot]

Many thanks, excellent replies.

Yes, I'd also heard Mercurial is more Windows-friendly, or was - I think git has pretty much caught up now.

[Sysman]

I was looking at this last week:

Stack Overflow:- What is the difference between mercurial and git

Git vs. Mercurial: Please Relax

The Differences Between Mercurial and Git

[d000hg]

I'd say "I don't know the differences, but I can tell you the difference between standard and distributed VCS". I think Mercurial is more Windows-friendly, is that true? And Kiln is based on Mercurial. Comparing two very similar products seems pointless unless it's a sysadmin type role?

Git Vs SVN is a whole world of change, that's for sure. Here's one low-brow article (he sells Kiln so it's biased though): Distributed Version Control is here to stay, baby - Joel on Software

[OwlHoot]

If an interviewer asked you to compare and contrast git versus Mercurial what would you say?

I haven't used either very much. But my impression is that Mercurial is slightly simpler, whereas git is a bit more flexible.

What if the interviewer threw SVN into the pot, and asked you to comment on that with reference to the other two? Obviously the repository is more centralized; but I wonder if there are other significant differences.

Anyone have any decent web references on this topic? Sometimes it's good to have detailed replies off pat to this kind of potential interview question.