In the recent years, the hype around Git raised greatly. Everybody knows about Git, nobody knows about alternatives.

Other ones like Mercurial seem to be unnoticed. Both have been released in 2005, and provide similar functionalities. Moreover, Mercurial is generally considered to be easier to use, more intuitive and had for a long time better UIs. Therefore, it could be assumed that this would be a popular alternative, especially for those new to distributed version-control. Yet, it seems unknown to most people, unlike Git which succeeded pretty well.

The point of this post is to try to understand this phenomenon better.

How comes Git gets all part of the cake? Did they somehow use better marketing? Is it because its community is more ...ahem ..."verbose"? Is it because of the "Linus" name? Is it because of its geeky image?

What's your opinion?

  • 64
    You are possibly right about Linus Torvalds being the sole reason for its popularity... Jul 29, 2011 at 8:24
  • 4
    I don't know, I feel they've been exposed to me in roughly equal amounts... although I did hear about git before hg. But yeah, Torvalds is a celebrity, so anything he's involved in is likely to get attention.
    – perp
    Jul 29, 2011 at 8:27
  • 13
    I like GitHub... that's all
    – cnd
    Jul 29, 2011 at 9:35
  • 7
    @jrwren, I will preface this comment by saying that I have used neither Git nor Mercurial. If I were to learn Git and then immediately learn Mercurial (or versa-visa), one of them would likely take me less time to learn. That one, the one that took less time, is the one I would consider to be easier to use. Grokking typically implies that it takes some time to understand, which is therefor harder to use. I'm not saying that would make a product worse, sometimes you need a steeper learning curve for more powerful tools, but it certainly changes the ease of use.
    – zzzzBov
    Jul 29, 2011 at 15:44
  • 8
    @MarkTrapp God, Mark! Looks like everyone was having a good discussion and then you had to come along and police everyone out the door. I wish I knew of a site like StackOverflow that allowed discussions. Aug 2, 2012 at 15:58

23 Answers 23


I believe services like GitHub or Gitorious is a big factor. It's important for people that they can host their stuff somewhere and especially GitHub is a great service for that.

For mercurial, there was no such service when DVCS became popular (at least none I was aware of). You have Bitbucket now and probably others, but GitHub has been there for quite some time, it's well-known and it gets better and better.

  • Add to this that some huge open source projects use git which sort of makes the decision for you. I have been "forced" to use git several times (for android for example) but I haven't been forced to use Mercurial or Bazaar. Also, I think git is great :) Jul 29, 2011 at 10:45
  • 11
    There's also Google Code and SourceForge for hg Jul 29, 2011 at 11:32
  • 7
    Git is boosted by Github which puts other repositories in the shade. Bitbucket has some advantages (free private repositories) but the UI is poor compared to Github Jul 29, 2011 at 15:10
  • 2
    I use Mercurial alone to talk to GitHub... the hggit plugin (hg-git.github.com) makes it possible to decouple the tool from the community. But maybe not from the community tools.
    – bpanulla
    Jul 29, 2011 at 15:29
  • 1
    CodePlex supports Mercurial as well. Jul 29, 2011 at 16:57

I see a lot of answers to this that rely on the feelings the author had when hearing about one or the other SCM. Others say it all was sheer luck. I believe luck can be traced back in history.

I will talk about history.

Git and Mercurial were created simultaneously in order to solve the same issue. Back in those days, the Linux kernel was forced to stop using BitKeeper, a proprietary distributed SCM which it had been using for 3 years. The reason for this was that Larry McVoy, CEO of BitMover, the company behind BitKeeper, stopped giving his software away for free to Linux developers, because someone inside the Linux community had reverse-engineered it.

Linus Torvalds, dissatisfied with what already existed, subsequently started to work on a brand-new SCM that he would soon call Git. Quickly thereafter, Matt Mackall started the Mercurial project for similar reasons.

After some time developing these projects separately, Matt Mackall presented an advanced version of his SCM and benchmarked it a certain way, comparing it to Git (which was itself only a couple weeks old). Linus considered using it instead of Git for Kernel development, but dropped the idea when he realized that Mercurial was using Changesets to log revision modifications. He feared that was too close to the way BitKeeper worked, and he certainly didn't want anything that could make someone say, "They built a BitKeeper clone".

Git was therefore used for Kernel development instead of Mercurial, but both were technically relevant. The end-result is, Git started out by being actually used where it was designed to be used, while Mercurial was not as fast to find its first big FOSS use. Because it was endowed with a very good design, and thanks to Matt Mackall's perseverance, it eventually became famous and got used for big, real-world projects.

Today, they are both famous. Which one is most famous is impossible to say. Google Code only integrated Git recently, while it had Mercurial for a long time. Many really big and famous projects use either.

I guess what I mean is, when the very reason why you have started a project vanishes, it is harder to gain popularity, but still feasible.

Bazaar is another SCM which is very famous in the GNU world, but not so much outside that, because it was built with the intent of satisfying the GNU community. Software often go where their creators want to go, and no further.

On the other hand, distributed SCMs are clear winners. I don't see many widely-used non-distributed SCMs out there.

  • 5
    I really appreciate this history.
    – jrwren
    Jul 29, 2011 at 14:54
  • 4
    @TMN You're right! In fact, when Andrew Tridgell's reverse-engineering came into light, and when Larry McVoy changed the licensing of BitKeeper, there was so much flame wars that Linus Torvalds decided to drop it, and gave himself a week to find a replacement. At the time, the real competitor was Monotone, but it was tearfully slow. Many people built replacements at the same time, and everyone was just happy to use the new tools. I think Git hit 1.0 first, then Mercurial; Bazaar took nearly two years. Jul 29, 2011 at 15:22
  • 7
    "I don't see many widely-used non-distributed SCMs out there." It depends on where you are in the industry. Perforce, ClearCase, and svn are still very widely used, just not so much (except for svn) in the open source world. Oh, yes, and Visual Source Safe and MS Team whatever-it-is in Windows shops.
    – Bob Murphy
    Jul 29, 2011 at 16:40
  • 13
    By "reverse engineering", you mean telneting to the server and typing "help" Jul 29, 2011 at 20:07
  • 3
    I would say this in general about both DVCS and CVCS: "All software partakes of the Tao and should not be scorned." "Including software from Redmond?" "Oh, gosh, look at the clock. Class dismissed."
    – Bob Murphy
    Jul 29, 2011 at 21:05

Linus Torvalds

Linus is a big advocate of Git and promoted it heavily to the core linux group for years and it's grown from there. I daresay it's entirely due to Linus's influence over the *nix community.

Personally I still use Subversion, but that's from preference rather than utility.

  • 12
    I don't think it's Linus personally so much as the huge visibility of Linux - There are few things you could tell someone with no prior knowledge about DVCS (or even software development in general) more likely to lend credibility than "it's used for the Linux kernel". Jul 29, 2011 at 9:23
  • 6
    Not only is he a big advocate of it - he is the one who created the original versions of it before he turned it over to Junio Hamano Jul 29, 2011 at 11:02
  • 44
    What? Why would you prefer Subversion? Jul 29, 2011 at 11:31
  • 12
    Don't you mean that you still use Subversion out of habit and inertia, rather than preference or utility? That's why I'm still using it, and I suspect most of the rest of us, too... Jul 29, 2011 at 13:16
  • 7
    @deadalnix: Because Linux, and Linux, has a horde of screaming fanboys unmatched by any other open source project. They function as a pretty effective street team for Git. Jul 29, 2011 at 16:55

The usual pain point with version control system is branch merging.

You need to have tried it when it doesn't work to understand how painful it can be and how important it is to have working, in order to be working freely with branches.

Learning that Linus Torvalds wrote git to do this right, and that allegedly in one situation he has used git to merge twelve branches together at once, this is a very convincing argument for git to be interesting.

I was in the situation about a year ago where I had to choose between hg and git, and the above merging was one important factor in choosing git. The second was that the Eclipse organization switched to git, so the Eclipse tooling was expected to be good for Java projects. With the release of Eclipse 3.7 this has happened. We were perhaps 6-9 months early on this.

For different needs hg might be just as useful. Sun chose it for their VCS based on a very careful investigation. You may want to find the white papers and see what their reasonings were.

EDIT: Note, I am not saying that there is anything Mercurial cannot do, just that for Java with Eclipse - which is our primary focus - the market forces are currently strongest for git, even under Windows, and we need to stand on the shoulders of others, not their feet.

  • 5
    +1 It's all in the branches. This analysis discusses the merging power of git in comparison with mercurial. Jul 29, 2011 at 12:21
  • 19
    @AmV: Please do not post obfuscated URLs. Jul 29, 2011 at 13:16
  • 3
    AmV-link: felipec.wordpress.com/2011/01/16/…
    – user1249
    Jul 29, 2011 at 13:30
  • 4
    I'm not sure I see your point here. You're saying that they're equally good at branching (Git does nothing that Mercurial cannot do), but because you need good branching, you chose Git?
    – jalf
    Jul 29, 2011 at 14:26
  • 8
    I've never seen any convincing examples of how Git is better at merging than Mercurial, and certainly not in this answer. It's almost like you're confusing Hg with SVN or CVS.
    – Aaronaught
    Jul 29, 2011 at 14:37

Instead of saying why git or mercurial is better and saying its the only reason its popular, I'm going to focus on the community.

As I highlighted earlier, the Git community is very loud and arrogant. Most will vigorously defend their precious program. Most of the Git vs Mercurial war's I've seen were started by git people who were wondering why everyone on the Earth isn't using the holy git. Sites like whygitisbetterthanx.com even show this arrogance in the introduction, which is written to flame bait others.

I'm not saying everyone is this way, but most of the time when I've encountered git people, pro-git websites, and pro-git blogs I felt like git was being shoved down my throat instead of offered as a viable DVCS system.

In contrast, other DVCS communities aren't as loud. I didn't know Mercurial existed till I saw a "Whats the best DVCS?" question on SO. While git appears everywhere, other DVCS's take time to find.

  • 16
    Isn't calling others arrogant a bit arrogant?
    – user1249
    Jul 29, 2011 at 9:57
  • 21
    @Thorbjørn: It is. Except when i do it; then it's just correct. Jul 29, 2011 at 10:05
  • 6
    I think you have grown quite allergic to git. I have read the introduction of whygitisbetterthanx and some of its content. I see nothing arrogant or provocative. It just has the normal bias, that anything intended to promote something has.
    – back2dos
    Jul 29, 2011 at 10:19
  • 5
    @back2dos: it is pretty arrogant in that it claims "Git is better than everything". And in that quite large chunks of its supporting argumentation is either wrong and uncorrected, or crossed out, and yet it somehow doesn't ever change their conclusion.
    – jalf
    Jul 29, 2011 at 14:52
  • 5
    @Agos: And almost all of which are not unique to Git. They just move the goalposts in order to exclude other products.
    – Aaronaught
    Jul 29, 2011 at 15:59

I don't think Mercurial is particularly low profile. Kiln is built on Hg & there has been good support in IDEs like Eclipse & Netbeans for a while now.

Most of the developers I talk to seem to prefer Hg because of the better Windows support. If we were Linux developers it might be a different story.

You're also missing "Bazaar" which is the real "forgotten DVCS".

Certainly I agree that Linus is a very charismatic guy and an alpha nerd almost without equal so a lot of people would gravitate to Git because of that. Also, the "Creation myth" of Git is very compelling with Linus labouring for 6 days to create Git and resting on the seventh - or something like that. When a product has a memorable story it is easier to gain traction.

  • 6
    ...totally agree with: "Bazaar" which is the real "forgotten DVCS".
    – dagnelies
    Jul 29, 2011 at 8:37
  • agree but the exposure hg has from kiln/joel is more recent than the exposure git has from linus. hg is playing catchup
    – jk.
    Jul 29, 2011 at 12:20
  • 2
    There are actually quite a few "forgotten DVCS" out there, though many of them would probably be better described as "low profile", "focused" or "niche". Jul 29, 2011 at 15:34

It's a humble opinion, but git might get all this hype because of two parameters:

  1. It's very efficient
  2. It's fun to use (in some kind of very specific computer scientist way)

Plus, git got some killer app like github, and some very popular projects decided to use it, which gave it a lot of visibility.

  • 4
    1. Is mercurial inefficient in some area? Actually, for a long time, it was more efficient over http, which is why google code included it since more than 2 years, compared to the git support which was announced last week and became only recently equally good over http. 2. OK 3. There is the equivalent bitbucket.org
    – dagnelies
    Jul 29, 2011 at 8:34
  • 1
    Did I say that mercurial was inefficient? I never used it, so I can tell.
    – Thibault J
    Jul 29, 2011 at 8:51
  • 4
    this doesn't address the question at all imho, at least not the "while other didn't" part
    – jk.
    Jul 29, 2011 at 9:51
  • 1
    Mercurial can't add "empty folders" to the repository (dunno if this has been fixed now) but when I had to chose a DVCS, I eventually went git for this purpose. I needed some empty folders. Jul 29, 2011 at 11:33
  • 4
    @MartínMarconcini What do you mean by "I eventually went git for this purpose"? git doesn't support empty folders either.
    – Max Nanasy
    Mar 8, 2013 at 2:48

There are three factors at work here, "beta geek media", "the time is right", and "follow the leader"

Beta Geek Media

There are a number of channels that get discussion of "geeky activities". They would certainly cover the appearance of a new version control system, but they cover git more. Why? Because Linus Torvalds wrote it initially, argued about it publicly, and used it as a solution to his well-publicized problem with bitkeeper. Effectively, any time there's a flame war on lkml, the beta geek media will write an article about it. Git discussion started on lkml, so it got more coverage than other alternatives. And the beta geeks who read slashdot like it's Variety ate it up. The ultimate outcome of that is that git has ten times as many articles as mercurial.

The time is right

Big open source projects with lots of contributors have problems with centralized source control. As open source grows, and projects become more likely to have many contributors, the problem gets worse. Linux is probably the most well know project suffering from this, but there are lots of others. With many projects reaching this point, some kind of advanced VCS was needed. Git, Mercurial, and Bazaar were the big winners here. Arch and Monotone were just a little too early, and missed out on the hype wave.

Follow the leader

Big projects have followers who check out and build the code regularly, even if they don't contribute. The followers become familiar with the tools needed to fetch the project they follow, so those tools get more use. Let's take a look at the "big draw" projects for the big three DVCSs:

  • Git: Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
  • Mercurial: Java, Mozilla, Python
  • Bazaar: Ubuntu, Emacs

Git has more "big draw" projects using it, thus more people are familiar with git, there are more git tutorials written.

  • 1
    You might be right, but your "big draw" list is a bit misleading/biased. Looking at the Bazaar site, they list quite a few other major projects: MySQL, Bugzilla, Debian, GNU all seem like pretty widely known ones. The Hg list is quite a bit bigger as well.
    – jalf
    Jul 29, 2011 at 14:50
  • @jalf: such a list must be subjective. I've compiled my own Linux and Gnome, but never Mozilla or Emacs. Others may be the exact opposite way. The question is really "how many people will pull this project from source control"? I listed the ones that seem most likely to me to inspire people to install a vcs to pull the current source. Jul 29, 2011 at 15:03
  • Fair enough. I assumed it was an attempt at an objective list (after all, lists of which major projects use each DVCS system should be easy enough to track down) :)
    – jalf
    Jul 29, 2011 at 15:06

It's mainly just self-reinforcing hype. Git is the most popular, so it gets the most publicity, which leads to it getting more popular.

Git, Hg and Bzr are all perfectly good DVCS systems, but a frightening number of people equate DVCS with Git, and think that all the lovely features of a DVCS are unique to Git. And so they use Git, and recommend Git, and say things like "Git is better because it can do octopus merges" (So can Bazaar), or "Git is better because it is distributed" (so is any DVCS, hence the name), or "Git is better because it makes branching and merging easy" (again, this is true of every DVCS).

Sadly, because I feel the alternatives have a lot to offer as well, and I'd rather people chose Git for its unique strengths, than simply because they think DVCS == Git.

When someone discover how clever DVCS'es are, by being pointed to one specific DVCS, they often don't go and tell others "hey, DVCS'es are great, you should use them", but rather, "the DVCS that I learned about DVCS'es from is great, you should use it".


Github. Github is a pioneer in social coding. It turned version control into a social platform which grabbed a lot of attention, and it obviously just supports Git. Social media = greater adoption. Bitbucket is gaining steam though an getting lots of new features, making it a likely rival :)


Well in fact I think the hype is about all DSVCs togethers.

But the git advocates are just more vocal, often more agressive in their comments to be honest and like to talk about it everywhere.

I suspect Mercurial to be widely used, certainly as often as git, maybe more (Microsoft and other big companies use it now), but people using Mercurial most often just wanted a DSVC they can grasp quickly, not something to base a religion on. So they are least vocal and more reactive in discussions than pro-active like some git users.

Bazaar isn't talked about a lot certainly because only few big known projects do use it and no other big companies than Canonical is known to use it. Compare to Google (git, mercurial, svn) and big open-source projects for example and you can see why it's not really talked about. Fossil is another one that is interesting for a a niche of devs, so I guess it's normal and fine to them to be heard of only by those who search the features they provide (like embedded wiki, issue tracking and forum).

That being said, I think we're slowly getting down the hype cycle and a lot of developers having used several different solutions can start to see wich one fit their needs.

Also, Google Code Hosting and SourceForge now allow both git and mercurial so it's becoming more a project-specific choice than before when you chose git because of GitHub features.

There is no real war, just an interesting variety of tools.

  • I wish the hype was about DVCS'es in general, but from everything I've seen, the hype is about Git, and most people think that DVCS and Git are basically the same thing.
    – jalf
    Jul 29, 2011 at 14:53

I know there are a lot of answers to this question already, but I felt I could add a bit more perspective.

I used Bazaar pretty much ever since it was created for various things. The biggest thing I used it for was the AllTray project, for which I am (presently) the sole developer and maintainer. Bazaar is nice. It just works, it stays out of my way, and almost never have I have to look at a --help page or the man page for it. That said, there are some downsides to it:

  1. A lot of functionality that it has which arguably should be part of the core VCS, isn't. Things like the ability to perform a bisection of history, to run long output through a pager, or to have “colocated” branches (e.g., git-style repositories) are supplied as plugins.
  2. A lot of the plugins are not all that stable. For example, the colocated branches functionality doesn't seem to work well on the server side (at least, I've never gotten it to work, it tends to error out saying that the branch at the given path doesn't exist when it's right there in front of you and you can see the bloody thing).
  3. It has no “clone” operation, you pull branches one at a time. You have to do extra work if you want to have a repository so that you can efficiently pull new branches.
  4. For some projects, it is painfully slow. Try “bzr branch lp:mysql” sometime.
  5. It lacks strong support for hooks; you can write bzr plugins that provide hooks, but there is not a standard way to have server-side arbitrary hook scripts.

I recently switched to git for AllTray development, and am very quickly considering migrating all my projects to git. There is a little more up-front time spent getting to know the ropes, but it seems to be well worth it. Some things that I have noticed:

  1. git clone is a relatively fast operation, and gives you information about all of the branches that exist in the repository that you cloned.
  2. Adding additional remote repositories is painless, and so you can track many different repositories that have multiple branches if you wish.
  3. The Pro Git book is available online and in multiple formats, including for eBook reader devices—and it is not a difficult read.
  4. git seems much easier to extend than Bazaar, and you don't have to use any one particular API to do it. (NB: this is both an upside and a downside.)
  5. git has bisection built-in, and I can't stress the utility of that feature enough.
  6. GitHub is rather nice.
  7. The gitosis system is also quite nice. I'm not even sure how one would implement that other than as a plugin in Bazaar, and I can't imagine it would be anywhere near as efficient.

Long story short: I've used bzr for a very long time, but git is quickly proving its awesomeness to me.


Using git, you tend to always stay in the same local directory when you do development, and simply do git checkout branchname to switch between branches (I use "lightweight" feature branches all the time, so this is a very important feature to me).

Looking at the Mercurial documentation and tutorials, it seems that the preferred way to deal with different branches of development is to create new repositories by cloning. This tutorial is an example.

I believe you can do the same thing in Mercurial as in git, but for some reason the Mercurial documentation (that I have read) almost always shows branching by creating a repository clone.

(I use git daily. I have little experience with mercurial, I have played with it and followed a few tutorials)

  • 2
    I used 'named' branches all the time in hg. It supports them well. hg branch foo, then hg up foo later on... Clone-for-branch has some strong weaknesses for ordinary development. Jul 29, 2011 at 15:46
  • Hmm, so you're saying that Git is better than Hg because while Hg supports the feature you care about, the Hg community consider an alternative approach superior?
    – jalf
    Jul 29, 2011 at 17:47
  • 1
    1: I wonder: Why the focus on "branch by cloning" in the Hg documentation (see for instance hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html and mercurial.selenic.com/guide)? To me, it just seems messy to have one repository per branch. 2: I am not saying git is better, my answer is more of an observation on a matter that to me (a Hg novice) looks like a difference between the two. The difference seems to be more cultural than technical, since Hg also supports "branch within same repository".
    – codeape
    Jul 29, 2011 at 19:20
  • 3
    Mercurial suffers from a lot of out-of-date inforamtion online; a lot of it propogated by people that use git and didn't keep up-to-date on mercurial's features as it evolved. Most of the old reasons to prefer cloned repositories no longer apply in Modern versions of mercurial (named branches can be closed now, and there is a bookmarks system that gives you a similar usage pattern to git branches if you like). Sep 2, 2011 at 21:16

I don't know how many such rants I've seen the last few weeks, but they all seem to consider it as fact that Mercurial and/or Bazaar are objectively better than Git. Usability seems to be a common theme. Yes, learning Git was surprisingly hard after using CVS and Subversion, but at this point I wouldn't want to trade it for any other VCS unless it constituted another paradigm shift. And pointing to a table of features is going to tell me very little about how flexible, extensible, secure, or effortless it is. For example, by default git-diff uses colors and a pager. Sure I can get the same with diff ... | colordiff | less -R or something, but it should be obvious why one is superior to the other.

  • I don't think the argument is that you should therefore switch - obviously using the tool you already know is easier than switching to another one, no matter how easy that other one is. I don't think any DVCS proponent could really claim you're missing out a huge amount by being on git instead of Bazaar or Mercurial, there's not that much between them.
    – ZoFreX
    Jul 29, 2011 at 22:03

To be fair, I think the git vs. mercurial advocates are few and far between compared to the git vs. centralized advocates. However, the reasons are easy to summarize:

Git is version control for programmers. Mercurial is version control for enterprises. Centralized was an adequate first try at inventing version control, especially considering it was designed before the personal computer revolution.

What I mean by version control for programmers is that programmers in general favor flexibility over ease of learning. After all, we're willing to spend years learning esoteric languages in order to have the flexibility to make computers do what the untrained cannot. Git gives programmers the flexibility to use it however they please, at the expense of it taking longer to learn how to use that flexibility safely. It allows restrictions to be put in place to enforce policies, but doesn't come that way out of the box. Note I said ease of learning rather than ease of use. Once you learn it, git is as easy to use as any other VCS, and often easier due to increased speed and features.

Some programmers learn enough to do what they want, then resist learning new ways to do it. Enterprises hire and employ many of these people, so they want any changes in tools they use to have a certain degree of familiarity. Enterprises also want their programmers to have enough flexibility to do their jobs, but not so much as to make training or initial migration difficult. This is where mercurial fits in. It has most of the power of git, but a somewhat easier migration path.

I don't think it's fair to say git is only popular because of the hype, or Linus' endorsement. That probably accounts for many people trying it, but they stick with it and promote it because it works well for them, pure and simple.


NetBSD development uses CVS and that's all that's important.


It's got a snappier, more pithy name that lends itself well for puns.


I recently was looking for a version control system for personal projects, so I just tried a bunch of them. I'm practically illiterate on the command line, and I had heard that although GUIs were available, Git was really intended to be used through the command line, which made me a bit hesitant. Honestly though, it was ridiculously easy to pick up, and I am really enjoying it. Documentation is a huge factor in adoption of a new technology, and Git has tons of ridiculously simple documentation that is clear and available. The other alternatives such as SVN and Bazaar were great, they just did not make it quite as easy as Git. Github is also a big factor, since it has become so central to the open source movement at the moment. Having a (ironically) centralized location to exchange code and projects through is a game changer in itself.


Just my 2¢ - I chose git over the alternatives because it's written in C rather than a radtool language or an overly-academic high level language. The benefits are that it's fast and efficient and that I can actually RTFS if I encounter bugs or behaviors I can't explain. It also makes it possible to use on tiny self-hosted development environments that don't include gigantic interpreters/runtimes, meaning I can directly pull from a git repo and compile on such systems rather than having to fetch latest source elsewhere and rsync.

  • 1
    That was also the reason why I've choose git, because it is written in a compiled language instead of python, and because of that I can simply have a portable version of git in my usb pen together with some other tools.
    – Coyote21
    Jul 29, 2011 at 19:58
  • And yet, this is precisely the reason Facebook chose to use mercurial instead: they weren't happy with the performance of either, but found it easier to improve the performance of mercurial (which was, for most operations, only a small percentage slower than git overall) by a signficant margin (which they did by integrating it with a file monitoring service so it could tell what could and could not have changed, see details here) because of the fact that python was easier to work with than C.
    – Jules
    Apr 15, 2018 at 3:33

You might be interested to read why the GNOME desktop project chose git over hg and bzr, when it decided to move from svn a few years back. There were many heated religious discussions along the way of course, but this GNOME Wiki page nicely summarizes the pros and cons as they applied to that particular community.


Not to mention Apple has now got involved with pushing it to the objective c community, if you've created a new application in Xcode 4 recently, you would have noticed that it automatically asks you if you would like to make a Git repo.

Granted Xcode 4 has only been around for a few months, and doesn't influence on Gits previous success, but we all know how popular Apple can make things in a short space of time.


I'm currently switching from hg (kiln) to git (github). I've used kiln for about a year right now. For me hg has no disadvantage. I can do everything I have to. So it's great.

Why am I using right now?

There are only three reasons right now.

  1. gitHub offers gists which are great
  2. gitHub offers great social features
  3. While doing developer presentations and workshops I always published my samples on hg and git. On git I've about 10 times more visitors than on hg!!

I think the third one is the most important one.



Pure luck I guess, until now almost impossible to prove why something worked and other did not. Linus can build something else spectacular and have no success.

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