Why did Git get so much hype? ...while others don't? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

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

Answer 11

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.

Answer 12

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.

Answer 13

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)

Answer 14

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.

Answer 15

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.

Answer 16

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

Answer 17

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

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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.

Answer 22

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

Answer 23

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.