Git and Mercurial

Question

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?

Answer 1

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

Answer 2

You may want to read this question on stackoverflow:

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

Answer 3

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).

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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

Mercurial, Subversion, and Wesley Snipes

Answer 8

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.

Answer 9

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.

Answer 10

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

Answer 11

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