Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I would like to know:

  • What's the difference between Git and Mercurial?
  • What are the pros and cons of using them?
  • How good is the Windows support for both tools?
share|improve this question
    
StackOverflow (stackoverflow.com) is a more appropriate place for this, though I'm not sure they're any more in favor of discussion-based questions with no clear answer than ServerFault. –  sh-beta May 27 '09 at 19:53
1  
well, scm is normally used by developers, but system admin uses them for deployment as well. that's why i've asked the question here. –  Michael Ellick Ang May 27 '09 at 21:37

11 Answers 11

up vote 12 down vote accepted

Some time back google did an analysis of Git and Mercurial. You can read it online on

http://code.google.com/p/support/wiki/DVCSAnalysis

share|improve this answer
    
This is an analysis made for python : python.org/dev/peps/pep-0374 –  hayalci Jun 11 '09 at 21:40

For a biased comparison, see Why Git is Better than X

share|improve this answer

Git and Mercurial have more in common than they differ. Both are excellent.

I use Mercurial and have no experience with Git. From friends that use Git I hear that it takes some getting used to, but after that it's awesome.

Windows support... I believe there are GUI front ends for both. Mercurial is written in Python, so no problems there.

share|improve this answer

I like Distributed Revision Control Systems: Git vs. Mercurial vs. SVN:

is a series of tools just like unix and contains a few layers such as it's plumbing and porcelin where as mercurial is more of a single tool ala svn.

I also found mecurial to work better on windows when I started to learn both. To be fair git for windows is pretty stable now.

share|improve this answer

You may want to read this question on stackoverflow:

What are the relative strengths and weaknesses of Git, Mercurial, and Bazaar?

share|improve this answer
    
yeah, DVCS discussions need to have bazaar thrown in. It has a very flat learning curve. –  hayalci May 29 '09 at 0:02

Found Distributed SCM in GNOME -> http://live.gnome.org/DistributedSCM

share|improve this answer

First, either one is going to be a huge step up from older systems - there's really not a bad option.

Git is a little harder to use but noticeably faster and arguably more powerful.

Mercurial is friendlier and - thanks to TortoiseHg - much easier to use on Windows.

In either case you have the option of excellent hosting (GitHub, Bitbucket, eventually Google Code), lots of guides and migration tools from other systems. If you need Windows users, I'd recommend Mercurial - otherwise it'd probably make sense to try both and see which one you prefer. I find Mercurial more comfortable but Git isn't that far behind and has some scary-cool features (i.e.rebase -i).

share|improve this answer

Here's an article about distributed SCMs by Eric Sink:

Mercurial, Subversion, and Wesley Snipes

share|improve this answer

One major win for Git is Github and the way it crosses source-hosting with a social-network to change the culture of your software project.

Although other dcvss are probably comparable technically, github looks to me like a real step forward culturally.

share|improve this answer

what's the difference between git and mercurial ?

There are numerous detailed DVCS studies out there (see links in the answers above). I liked this recent blog: http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/ and quite agree with it. The major plus for git today (beginning of 2010) is probably github! :-)

what are the pros and cons of using them ?

Unless you have very peculiar requirements, I would say that for 99% of the time both are very good at doing what you need.

I heard that Git windows support wasn't good (i.e., requires Cygwin which most windows dev do not have) but after seeing a demo of TortoiseGit I would say it's not true anymore.

Also I heard that you can obliterate files/dirs in Git easily and not in Mercurial but I just found that with convert --filemap it's easy as well! Also extensions in shell or Python can be very powerful (to create commands etc.) and the Queue extension allows to clean history by rebasing, like in Git.

In summary differences tend to get smaller: have a look at both and choose which ever, they are both good. If you already know subversion for example, Mercurial might be easier to handle as the similar commands do match more than in Git.

how good are the windows support for both tools ?

See above.

Hope it'll help.

Cheers,
Christophe.

share|improve this answer

For a sysadmin, I believe backwards compatibility, stability, robustness, security, and backup are important topics then it comes to deploying a new tool. I can give you some information about Mercurial:

  • Backwards Compatibility: Mercurial has a stated policy on backwards compatibility. The rules say that different versions of Mercurial must always be able to talk to each other over HTTP(S) and SSH.

    This means that you can safely upgrade clients without upgrading the server at the same time. You can also do the opposite and upgrade the server alone, but this is normally much less important since new features show up in the clients and often wont require anything from the server.

    The on-disk format sometimes change — we've had 4 changes until now. When that happens, old clients will refuse to operate on the repository on disk (but remember that they can still push/pull over the network). New clients can still read/write old repository formats and will never automatically upgrade an existing repository to a new format in case the repository is shared with an old client over, say, NFS. All in all, we try to make upgrades painless.

  • Output Stability: This is closely related to the above. As part of the compatibility rules, we also ensure that the output of Mercurial is stable. This means that the shell scripts you write today, will continue to work tomorrow.

  • Robustness: Like Git, changesets are identified by a cryptographic hash value that is computed over each change and the parent changesets. This makes it infeasible to change any part of the history without it being noticed. The hashes are verified every time a file is checked out.

    Mercurial repositories consist of a lot of revlog files. They are designed to be append-only, which makes it possible to repair some forms of hardware corruption by simply truncating the files. You can always use hg verify on a repository to make Mercurial double-check that everything is as it should be.

  • Security: When repositories are hosted using SSH, all the normal rules for access control applies — Mercurial is not doing anything special. So if I can log in and read the files in your repository, then I can also make a clone. If I also have write access, then I can push to the repository. Managing this is therefore easy: just setup a group and make sure that new files are made writable by the members of the group.

    When hosting with HTTP(S), it is the front-end webserver that handles authentication. We provide a CGI (with FastCGI, WSGI, and ISAPI flavours) that interacts with the repository, but the script is not doing authentication. This means that it's easy to integrate Mercurial with existing setups: if you're already using Active Directory to authenticate users, then you're all set for using AD with Mercurial. See this question for more about AD and Mercurial.

    Finally, instead of using the hgweb CGI script we supply, you can use something like RhodeCode. That is discussed further in this question.

  • Backup: With the append-only design, you can almost just copy a "live" repository to make a backup. However, it can happen that you get too much data that way since a backup program might copy the "changelog" before it copies the "manifest", whereas Mercurial writes the manifest before it writes the changelog. The changelog references the manifest, so the backup will end up with an un-referenced entry in the manifest. Running hg verify will detect this and hg recover can rollback the incomplete transaction.

    The proper way to do backups is to use hg clone. That will make sure to copy a consistent snapshot, even when people are pushing data into the repository while the backup is running. Since you can clone over the network, you can easily send the data to an off-site machine for safe keeping.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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