Git vs Mercurial

From WikiVS, the open comparison website
Jump to: navigation, search
Git Mercurial

Git and Mercurial are the two most popular Distributed Version Control Systems (DVCS).

Design and Workflow[edit]

Mercurial is generally believed to be simpler and easier to learn than Git. In turn, there is often the perception that Git is more flexible and powerful. This is due, in part, because Git tends to provide more low-level commands, but also in part because the default Mercurial tends to hide advanced features, leaving it to users to edit the mercurial config file to activate the advanced features they like. This often leads to the perception that advanced features are not available in Mercurial. On the other hand, Git has improved both in documentation and ease of use, helping bridge the usability gap with Mercurial.

In both Git and Mercurial the local repository is in a hidden directory that appears at the top level of the working directory. The work files then appear in that work directory along side the repository. If no work files have been checked out from the repository into the local work directory, the repository is said to be 'bare'.

Updating the local repository from a remote repository is called 'pulling', while updating a remote repository from a local one is called 'pushing'. In both Mercurial and Git propagating changes from the working directory to remote users is a multistep 'workflow', where the programmer first puts changed files into the local repository, and then pushes these changes to a remote repository, and vice versa.

But at this point there is some divergence in the recommended workflows. In the Git recommended workflow changes are pulled just as easily from working or bare remote repositories, but pushing is only simple/recommended going back to a bare remote repository. However, in the Mercurial workflow pushes can be made just as easily to remote working repositories as to remote bare repositories.

Thus, with the Git workflow the local repository for a working directory can only change as a consequence of the programmer owner's actions, typically by doing a 'pull'. In contrast with Mercurial workflow the repository local to a working set of files can change due to an external push. On the other hand, with the Git workflow the repository on the server can not easily be a working directory without making a duplicate work repository on the server or without risking that pushes will be rejected with errors due to the 'main branch being checked out'. With Mercurial one may work on the server repository without such hazards.


Git Mercurial
git pull hg pull -u
git fetch hg pull
git reset --hard hg update -C
git revert <commit> hg backout <cset>
git add <new_file> hg add <new_file> (Only equivalent when <new_file> is not tracked.)
git add <file> Not necessary in Mercurial.
git reset Not necessary in Mercurial.
git add -i hg record
git commit -a hg commit
git commit --amend hg commit --amend
git blame hg blame or hg annotate
git blame -C (closest equivalent): hg grep --all
git bisect hg bisect
git rebase --interactive hg histedit <base cset> (Requires the HisteditExtension.)
git stash hg shelve (Requires the ShelveExtension or the AtticExtension.)
git merge hg merge
git cherry-pick <commit> hg graft <cset>
git rebase <upstream> hg rebase -d <cset> (Requires the RebaseExtension.)
git format-patch <commits> and git send-mail hg email -r <csets> (Requires the PatchbombExtension.)
git am <mbox> hg mimport -m <mbox> (Requires the MboxExtension and the MqExtension. Imports patches to mq.)
git checkout HEAD hg update
git log -n hg log --limit n
git push hg push


Git is often faster than Mercurial on Linux and other open source Unix-like systems, though this depends on the operation. For instance, significantly slower initial clones across the network are reported for Git but most commit, pull, and merge operations are a bit faster with Git. All in all, both systems have very good performance and both are used in large projects with long histories.

However, Git is faster than Mercurial for network operations.

A test on using Git and Mercurial as data backend for a server showed that storing new changes is slightly faster in git, but suffers irregular heavy performance drops. Also the time for garbage collection and strong size fluctuation in Git is significant on servers[1].

Traditionally, Git's performance on MS Windows has tended to lag because of Git's POSIX-centric architecture, causing some POSIX type concepts to have to be emulated on Windows with direct ports that link against Cygwin. However the msysgit project provides a native port instead of an POSIX emulated port that has shown to increase performance dramatically [2].

Philosophy of implementation[edit]

Git is based on the Unix philosophy of having one application provide one functionality. Git used to consist of 144 executable files that each do a certain job within a Git repository. Originally the user called the different subprograms directly, but now a frontend is used to hide this implementation detail from the user.

Mercurial, on the other hand, integrates all its functionality under one Python frontend.

Additionally, Mercurial supports an extensive set of extension plug-ins. In Git, it is possible to link the libgit library to build your own tools and extensions but this has some limitations, however the libgit2 project aims to fix this. With Git, you can build your own functionality on top of the low level Git commands as well.


Both Git and Mercurial are copyleft open-source projects, using the GPL for most if not all source code. In case of git it is GPLv2 only, while Mercurial uses GPLv2 or later, which gives compatibility with projects licensed under GPLv3 and Apache.

Hosting Provider Support[edit]

Sometimes developers find it useful to outsource management of their revision control systems. With distributed version control systems, of course, there is no need for a centralized repository, however the option to ignore the presence of a central repository does not negate the usefulness to selectively embrace centralization.

Here is a listing of hosting providers, whether they support Git, Mercurial, or both, whether their services are free to FOSS projects, and whether they accept payments for proprietary projects.

Provider Git Mercurial Free hosting Premium hosting
Javaforge x x x x
Gitorious x x x
GitLab x x x
GitHub x x x
Codeplex x x x x x
Codebase x x x x
Google Code x x x ?
BitBucket x x x x
SourceForge x x x ? x x x x
ProjectLocker x x x
Kiln x x x
Codeplane x x
Assembla x x x x


Git is written in C, Bourne shell, and Perl. Mercurial is written in Python and C.

Git was created by Linus Torvalds for the purpose of maintaining the Linux source code repository in the wake of BitKeeper support being pulled from the project. About the same time, Matt Mackall wrote Mercurial for much the same purpose. In part because it was declared finished a few days earlier, and in part because Linus Torvalds created it, Git was adopted by the Linux kernel project instead of Mercurial.

Mercurial's development in portable languages has made porting it to MS Windows and other non-Unix-like systems easier than Git's use of the Bourne shell. Initially, the majority of Git's code was written in Bourne shell, but over time more and more of it has been translated to C, both for performance purposes and for portability.


Git started its popularity by becoming the official version control system for the Linux Kernel.

Even apart from the Linux Kernel, Git is quickly becoming popular among open-source hackers, and has already shown extreme popularity among programmers of many languages, though Mercurial has enjoyed substantial adoption by developers across a wide range of languages as well.

The Python language's development has now been moved to Mercurial, and many projects written in Python are switching to it as well.Template:Citation needed Mozilla is now also using Mercurial for its various projects [3] and Facebook is a heavy user of Mercurial [4]. By contrast, Git is used more heavily by Ruby and Perl developers than Mercurial, though of course, there are exceptions. Git is also included with Apple's Xcode 4 as the primary version control system for new projects, and Xcode's integrated version control tools only support git and SVN integration.

Compatibility to other VCS[edit]

Git provides bidirectional functionality between SVN and Git. (git-svn) Mercurial provides similar functionality via the hgsubversion extension. Mercurial's hg-git extension allows interoperability between Mercurial and Git.