129

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?

dagnelies
  • 5,415
  • 3
  • 20
  • 26
  • 64
    You are possibly right about Linus Torvalds being the sole reason for its popularity... – Robert Koritnik Jul 29 '11 at 08: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 '11 at 08:27
  • 13
    I like GitHub... that's all – cnd Jul 29 '11 at 09:35
  • 3
    your premise that "Mercurial is generally considered to be easier to use... " is false. Only people who haven't grokked git think that :) confession: I used to be one of them. I'm not anymore. – jrwren Jul 29 '11 at 14:52
  • 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 '11 at 15:44
  • @Robert git is extremely popular even among Mac users, which may admire Linus as much as every other geek, but are probably not very attracted to a product just because of his name – Agos Jul 29 '11 at 15:46
  • 3
    Obligatory: http://gitvsmercurial.com/ – Brook Jul 29 '11 at 15:58
  • As a not-real programmer, I'd only heard of git because the Ubiquity Firefox extension used https://gist.github.com/ – endolith Jul 29 '11 at 16:25
  • 1
    In the beginning, hg *was* easier to use than git. But that gap is long gone. – Randal Schwartz Jul 29 '11 at 16:53
  • I think the answers here collectively make up a pretty accurate answer. Rather than answer your question, most Git users who found it simply parrot "Git is better than Hg because , even though I've never used Hg, and don't know whether it supports the same feature", which, while it doesn't answer your question in any way, helps spread the word about Git, and thus, hypes Git more than "the others". – jalf Jul 29 '11 at 17:50
  • 1
    @jrwren - That's because `git` is really *intuitive*, once you know how it works. *8') – Mark Booth Jul 29 '11 at 21:04
  • Idle speculation and discussion is not on-topic here. Please see [Good Subjective, Bad Subjective](http://blog.stackoverflow.com/2010/09/good-subjective-bad-subjective/) for more information. –  Jul 29 '11 at 21:45
  • 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. – Theodore R. Smith Aug 02 '12 at 15:58
  • @jalf "Git is bettern than Hg because of Git's branches." – remmy Nov 09 '12 at 18:34
  • For a counterexample, I learned about Mercurial a year before git, and what makes this interesting is it was already 2011. I think this was due to google code. – n611x007 Jun 27 '13 at 14:20
  • Xcode comes with git, lets you easily create git repos, and do all the basic operations for single and multiple users without any knowledge of git. That alone gives you gazillions of users. – gnasher729 Apr 15 '18 at 13:19

23 Answers23

88

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.

daaawx
  • 101
  • 1
  • 3
deadsven
  • 301
  • 2
  • 7
  • 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 :) – FeatureCreep Jul 29 '11 at 10:45
  • 11
    There's also Google Code and SourceForge for hg – configurator Jul 29 '11 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 – iandotkelly Jul 29 '11 at 15:10
  • 2
    I use Mercurial alone to talk to GitHub... the hggit plugin (http://hg-git.github.com/) makes it possible to decouple the tool from the community. But maybe not from the community tools. – bpanulla Jul 29 '11 at 15:29
  • 1
    CodePlex supports Mercurial as well. – Grant Palin Jul 29 '11 at 16:57
  • Google Code and SourceForge both support Git now. – mkchandler Jul 29 '11 at 18:26
  • Not completely reliable as an indicator, but the first crawl of github.com in the archive.org database is [May 2008](http://web.archive.org/web/20080514210148/http://github.com/), and the first crawl of bitbucket.org is [June 2008](http://web.archive.org/web/20080607201648/http://bitbucket.org/) (ignoring the crawls which obviously weren't the current website). – robertc Jul 29 '11 at 21:02
  • The thing about github is that seemingly _everyone_ uses it; if I want to fork someone else's project they are likely on github which makes doing so (and the subsequent pull requests) simply. – Callum Rogers Aug 05 '11 at 06:36
  • Please update this answer. Gitorious has been absorbed into GitLab. – Josiah Jun 27 '17 at 14:53
87

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.

Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
Thaddee Tyl
  • 131
  • 1
  • 6
  • The very interesting question is whether that the stopping of free versions of BitKeeper for Linux - when seen in hindsight - was the killing blow for BitKeeper? –  Jul 29 '11 at 14:21
  • BitKeeper is not dead; a couple of commercial companies are using it. On the other hand, no sane open-source developer will ever consider it. It is technically behind Git and Mercurial, maybe even Bazaar! It is sad, but [their comparison sheet](http://www.bitkeeper.com/Comparisons.html) is very false (well, we don't know what they mean by "Other SCM"). – Thaddee Tyl Jul 29 '11 at 14:52
  • 5
    I really appreciate this history. – jrwren Jul 29 '11 at 14:54
  • 1
    IIRC, BitKeeper didn't have a lot of competitors until Git and Mercurial appeared. I'm sure the FOSS community rallied behind these projects, and there was likely some backlash against BitKeeper that allowed the new projects to gain mindshare. These were probably the two major deciding factors. – TMN Jul 29 '11 at 15:02
  • 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. – Thaddee Tyl Jul 29 '11 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 '11 at 16:40
  • @Bob Murphy: true, distributed models are not so much in use in commercial companies. I guess they don't really see the point given that they are all supposed to be working in the same building. Would they benefit from it? It would help them ease merging, for one. Maybe they're afraid of the change. Big companies tend to have huge inertia. – Thaddee Tyl Jul 29 '11 at 16:53
  • 1
    @Thaddee: I can say from personal experience that's not it at all. Successful companies aren't that dumb - it's more often about the nature of the software being developed, the development model, and whether DVCS or centralized fits better. I could give lots of examples, but for instance, game companies typically use Perforce because it's insanely faster than something like git at managing large binary assets like audio files, 3D scenes and models, and raster images. – Bob Murphy Jul 29 '11 at 18:04
  • Isn't visual source safe the joke of all version control systems? – Coyote21 Jul 29 '11 at 19:39
  • 13
    By "reverse engineering", you mean telneting to the server and typing "help" – alternative Jul 29 '11 at 20:07
  • Also, I love that comparison. All Yes on one side, no Yes on the other... Then again, they don't have any Distributed VCS's on the comparison page... – alternative Jul 29 '11 at 20:08
  • @Coyote21: Yup. What's really sad is, SourceSafe *before* Microsoft bought it was actually quite good for the time. However, I cannot tell you how much time and money the company I used to own wasted on corrupted VSS databases. – Bob Murphy Jul 29 '11 at 21:01
  • 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 '11 at 21:05
  • @BobMurphy - there's no such thing as software *from* Redmond. Everyone knows that Redmond is where software goes to die. All the real software in the vicinity *came* from Seattle. – Jules Apr 15 '18 at 03:24
78

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.

Justin Shield
  • 2,837
  • 18
  • 22
  • 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". – Michael Borgwardt Jul 29 '11 at 09:23
  • 1
    @Michael Borgwardt - You do tend to have huge personalities connected to some of these famous programs or frameworks. Without those personalities driving interest I'm not sure that they would be quite as popular. Udi Dahan with NService Bus, Ayende Rahein with RavenDB or Rhino Service Bus, Nicholas Blumhardt for autofac, etc. – Justin Shield Jul 29 '11 at 09:31
  • 1
    @Michael, the huge visibility of Linux means that people know Linux works and is of high quality, and extends this expectation to git. –  Jul 29 '11 at 10:31
  • 6
    Not only is he a big advocate of it - [he is the one who created the original versions of it](http://git-scm.com/about#authors) before he turned it over to Junio Hamano – Marco Ceppi Jul 29 '11 at 11:02
  • 44
    What? Why would you prefer Subversion? – configurator Jul 29 '11 at 11:31
  • 11
    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... – Cody Gray - on strike Jul 29 '11 at 13:16
  • This answer is mostly incomplete, and probably misleading. Yes, git is promoted by the linux kernel that give it a big influence. But it has been implemented in the first place because of limitation of some others versioning tools at the time that was making them unpractical for linux kernel. Git popularized the concept of distributed verioning tool, and this is why people switch to it. Obviously, other tools has the same capability. This answer is even particularly dumb because it makes a unproven assumption. Why linux kernel ? Why not mozilla source repos (mercurial) ? – deadalnix Jul 29 '11 at 13:17
  • 5
    @configurator, most likely out of habit. git is hard to learn _well_. –  Jul 29 '11 at 13:29
  • 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. – Tom Anderson Jul 29 '11 at 16:55
  • @Thorbjørn But you can use hg, which is very easy to learn! – configurator Aug 01 '11 at 10:37
  • 2
    @configurator, sure. Let's see if you can convince the OP. –  Aug 01 '11 at 10:45
  • 3
    I was going to +1, but then I read the last paragraph :P. – crazy2be Aug 08 '11 at 03:00
34

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.

Doppelganger
  • 101
  • 2
  • 5
    +1 It's all in the branches. [This](http://goo.gl/JmctW) analysis discusses the merging power of git in comparison with mercurial. – Amelio Vazquez-Reina Jul 29 '11 at 12:21
  • 19
    @AmV: Please do not post obfuscated URLs. – Cody Gray - on strike Jul 29 '11 at 13:16
  • 3
    AmV-link: http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/ –  Jul 29 '11 at 13:30
  • Fun thing, they mention Monotone. _NOW_ there is a serious contender for the "forgotten DVCS". –  Jul 29 '11 at 13:31
  • 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 '11 at 14:26
  • 2
    @jalf, no I do not say that. –  Jul 29 '11 at 14:27
  • 1
    That's how I interpreted it. Perhaps you could elaborate then? – jalf Jul 29 '11 at 14:32
  • 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 '11 at 14:37
  • @jalf, I said that git could do branching very well. This combined with the Eclipse migration to git was what did it for us after a "will git do?"-period. I have not investigated to see if Mercurial could do thirteen branches at the same time. –  Jul 29 '11 at 15:25
  • 2
    @Thorbjørn: let me rephrase then: In a question of why Git gets more attention than other DVCS'es, your answer is that "Git does what I need, I haven't checked if that actually sets it apart from other DVCS'es"? In that case, it fails to answer the question, doesn't it? – jalf Jul 29 '11 at 15:44
  • @jalf, well, it lived up to the hype. Can Mercurial merge 12 branches at a time? –  Jul 29 '11 at 15:48
  • @aaronaught, if that is required for you to be able to not use degoratory terms, I'll do my best. –  Jul 29 '11 at 17:28
  • @Thorbjørn: I know bazaar can. I'm not familiar enough with Hg to say (although a quick Google seems to indicate that it cannot). However, are you really suggesting that the ability to perform octopus merges is what makes one DVCS better than another? It's not a very common scenario for most people, is it? And again, whether or not Hg has the features you're looking for is pretty irrelevant when you base your answer on "Git is better than Hg *because I haven't investigated Hg's capabilities*" – jalf Jul 29 '11 at 17:44
  • 1
    Especially because, and this is the funny part, "Git is better than Hg because " *doesn't actually answer the OP's question!* – jalf Jul 29 '11 at 17:52
  • @jalf, "Git is better than Hg" if you develop Java with Eclipse. –  Jul 29 '11 at 18:26
  • 2
    This answer really doesn't answer the question. It explains why git is better than SVN very well, but not really why moreso than hg. Prior to the Eclipse switch to git, the Mercurial tooling in Eclipse was far better than the git plugin. – ZoFreX Jul 29 '11 at 21:18
  • What was Eclipse using before Git? – 700 Software Mar 04 '15 at 15:27
  • My first introduction to git was a discussion with a git fan, who told us how everything was so easy with git. And then it turned out that branch merging with git is exactly as difficult as with Perforce, for example. – gnasher729 Apr 15 '18 at 13:23
22

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.

qyb2zm302
  • 101
  • 3
TheLQ
  • 13,478
  • 7
  • 55
  • 87
  • 16
    Isn't calling others arrogant a bit arrogant? –  Jul 29 '11 at 09:57
  • 21
    @Thorbjørn: It is. Except when i do it; then it's just correct. – Tom Anderson Jul 29 '11 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 '11 at 10:19
  • I think this illustrates your point well http://www.quickmeme.com/meme/1kxc/ – Brook Jul 29 '11 at 12:31
  • @back2dos: If by "normal bias" you mean "making sh*t up" then yes. It's basically a giant eruption of ostrich arguments. "Git can do X but Hg can't!" - "Uh huh, and why would you want to do X?" - "...because SHUT UP, that's why!" – Aaronaught Jul 29 '11 at 14:42
  • 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 '11 at 14:52
  • @Aaronaught whyisgitbetterthanx.com lists 9 (nine) features, all of which highly desirable and worthy of being promoted. – Agos Jul 29 '11 at 15:52
  • 5
    @Agos: And almost all of which are *not* unique to Git. They just [move the goalposts](http://en.wikipedia.org/wiki/Moving_the_goalposts) in order to exclude other products. – Aaronaught Jul 29 '11 at 15:59
14

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.

mcottle
  • 6,122
  • 2
  • 25
  • 27
  • 6
    ...totally agree with: "Bazaar" which is the real "forgotten DVCS". – dagnelies Jul 29 '11 at 08: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 '11 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". – John Gaines Jr. Jul 29 '11 at 15:34
13

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.

Thibault J
  • 1,481
  • 8
  • 11
  • 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 '11 at 08:34
  • 1
    Did I say that mercurial was inefficient? I never used it, so I can tell. – Thibault J Jul 29 '11 at 08:51
  • 4
    this doesn't address the question at all imho, at least not the "while other didn't" part – jk. Jul 29 '11 at 09: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. – Martin Marconcini Jul 29 '11 at 11:33
  • 1
    @Martin no you cant add empty folders by design - but i'd never want to - at the very least i'd want a readme in the folder explaining why an apparently useless folder exists - more likely i'd just create the folders as part of the build script – jk. Jul 29 '11 at 12:15
  • @jk there are multiple reasons to store empty folders. Not everything we put into Source Control is code. – Martin Marconcini Jul 29 '11 at 18:02
  • @arnaud: Mercurial inefficient? [At least there is an issue with renaming files as mentioned in a G+ Post by Jon Skeet](http://goo.gl/9RwOb) – mbx Jul 29 '11 at 19:07
  • @jk - you may never have wanted to, but a lot of other people have. I'm one. Having to add a README file to every empty folder just to get the repo to propagate it is a pain. Can you imagine if your disk FS did that? – LarsH Jul 29 '11 at 20:53
  • 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 08 '13 at 02:48
12

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

jalf
  • 2,192
  • 1
  • 18
  • 22
12

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.

Sean McMillan
  • 5,075
  • 25
  • 26
  • 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 '11 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. – Sean McMillan Jul 29 '11 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 '11 at 15:06
11

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

DelvarWorld
  • 21
  • 2
7

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.

Sean McMillan
  • 5,075
  • 25
  • 26
Klaim
  • 14,832
  • 3
  • 49
  • 62
  • 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 '11 at 14:53
6

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.

Michael Trausch
  • 299
  • 2
  • 5
5

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)

codeape
  • 487
  • 2
  • 10
  • 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. – Paul Nathan Jul 29 '11 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 '11 at 17:47
  • 1
    1: I wonder: Why the focus on "branch by cloning" in the Hg documentation (see for instance http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html and http://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 '11 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). – Stephen M. Redd Sep 02 '11 at 21:16
4

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.

l0b0
  • 11,014
  • 2
  • 43
  • 47
  • 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 '11 at 22:03
3

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
2

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

Jonathan Cline IEEE
  • 906
  • 6
  • 8
2

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

Apophenia Overload
  • 263
  • 2
  • 6
1

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.

Morgan Herlocker
  • 12,722
  • 8
  • 47
  • 78
1

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.

R.. GitHub STOP HELPING ICE
  • 656
  • 5
  • 10
  • 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 '11 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](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/)) because of the fact that python was easier to work with than C. – Jules Apr 15 '18 at 03:33
1

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.

calum_b
  • 109
  • 1
  • 3
0

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.

tutts
  • 485
  • 1
  • 4
  • 5
-1

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.

Thorsten

Thorsten
  • 1
-2

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.

Acaz
  • 1
  • 1
  • 2