
Why did Git become so popular? - ashishgandhi
http://programmers.stackexchange.com/q/177875/5940
======
secure
cross-posting my answer here:

The package "gnuit" (GNU Interactive Tools, a file browser/viewer and process
viewer) was called "git" in Debian up until 2009-09-09, while git was called
"git-core".

Therefore, a better graph to look at is:

[http://qa.debian.org/popcon-png.php?packages=git-
core%20git&...](http://qa.debian.org/popcon-png.php?packages=git-
core%20git&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1)

Which shows that the popularity did not rise dramatically (take the green line
for the left part until they cross, then take the red line).

~~~
pseut
> Which shows that the popularity did not rise dramatically (take the green
> line for the left part until they cross, then take the red line).

It's less dramatic, but it does look like there's a pretty substantial
increase that can probably be attributed to "using an easier to discover
package name." Out of (genuine) curiosity, does the graph include Ubuntu
users?

~~~
secure
The graph does not contain Ubuntu users. Ubuntu also uses popularity contest,
but with a separate database from Debian.

The number of popcon submissions in Ubuntu is one order of magnitude higher
than the number of popcon submissions in Debian.

Unfortunately, I cannot find out whether Ubuntu makes the graphs publically
accessible like Debian does.

------
fbuilesv
I think the current answer fails to mention two important things:

1\. GitHub.

2\. Linus himself wrote it (the kernel previously used BitKeeper but that
never got any real traction AFAIK).

Having said that, I think this phrase totally nails it:

 _"If it's good enough for the Linux kernel, it's good enough for you" is a
very convincing argument._

~~~
ashishgandhi
GitHub was founded in 2008. The spike is in 2010-01. That's what the question
mentions too.

~~~
shantanubala
I'd argue that GitHub became _really good_ 2010-01. It takes a certain number
of early adopters to group together before the social features finally become
useful for everyone.

~~~
wyuenho
That also happened to be the time when people REALLY wanted to use DVCS but
Google Code lacks private repo ability and BitBucket was also getting really
unstable. BitBucket was far more stable than Github the years prior to 2010.
Mercurial also had a whole lot more GUIs to choose from and worked great on
Windows.

For the longest time Github just wouldn't send a tar ball when you clicked the
download button. And then around 2010, BitBucket was doing a lot of stuff
behind the scene and the service was down a lot. A lot of basic features just
wouldn't work. They were probably getting ready to sell to Atlassian.

I think that's the main #1 reason Git and Github took off.

Another one is Linus' diatribe on SVN. That video on youtube's been viewed
millions of times. The video really got the Linux fanboys jumping around all
excited even though its command line interface sucks and didn't work quite
well on Windows.

------
silverbax88
Having used ClearCase, CVS, Subversion, TFS, Git and Mercurial, I would have
to say it's because not enough people have tried Mercurial. I have no interest
in Git, but I think people like GitHub (or maybe don't know about BitBucket)

~~~
ajross
This contains the answer for why git won: Mercurial people have "no interest"
in it. What that tells me is that you have no interest in working with the
community and contributing to other peoples' projects, most of which use git
these days. Sure, if you want a SCM for your own team or your own private use,
you can make a strong case for hg being "better". _But that's not what SCM is
for._

Using it in your own ivory tower isn't going to impress anyone for the simple
reason that no one sees it. Instead, people look at the broader world of all
the interconnected git archives in the linux and web development communities,
get excited, pull repos and learn git. There's just no equivalent in the hg
community that I see. You guys have walled yourselves off, and it's killing
your software.

~~~
anonymous
I looked at mercurial once. I didn't start using it, because it has a more
complicated vocabulary than git.

Git just has a directed acyclic graph and pointers to the nodes of it. That's
all. End of story.

Mercurial has the concept of a branch, a tag and so on as seemingly separate
axiomatic things. It's not as stupid.

I like stupid.

~~~
micampe
Subversion is really simple too: it only has files and directories, branches
are directories, tags are directories. I don’t think stupid and simple worked
very well in that case.

Arguments can be made for both sides, picking a single design decision and
saying that that’s obviously better is not going to work. Implementation and
(especially in a case like distributed systems) network effects are much
stronger than any single isolated design decision.

~~~
Aga
Albert Einstein is attributed with a great quote: “Everything should be made
as simple as possible, but no simpler.”

I would argue that in the case of Git it's not about a single design decision.
The whole design is very simple and easily understandable. Thus everything can
be derived from the design decisions.

The design decisions also have clear rationales.

"Why something is better" and "why something has "won"" are of course
different questions that deserve different answers.

~~~
micampe
Having taught Git to a number of people, I disagree that it’s easily
understandable. It’s easy to understand the general idea of how it works, but
actually productively using it is an entirely different matter.

Of course, I may also be a terrible teacher.

~~~
Aga
I too have been teaching Git for many years now.

I find it easy to teach, thanks the concepts being simple and clear. I don't
have to transfer a lot of information before people can start reasoning about
things themselves and independently finding out more.

I always try to make sure people understand two things:

1) The history tree (==how to read the metro-map that is gitk)

2) Distribution, that you are responsible for syncing with others, not the
other way round

Almost everything else I prefer the students at least try to figure out
themselves.

------
ewood
I worked at a company where we migrated from CVS to Mercurial in 2009 and then
to Git a year later. I would say that the general move to distributed source
control away from CVS/SVN style centralised systems picked up steam from 09
onwards, and for us Mercurial won over Git initially because it had better
Windows support. While I loved Mercurial's more simple command syntax, moving
to Git was a no-brainer after we'd been bitten by Mercurial's poor handling of
large binary files and Msysgit had improved the Windows support situation.
This blog post ([http://blog.extracheese.org/2010/05/why-i-switched-to-git-
fr...](http://blog.extracheese.org/2010/05/why-i-switched-to-git-from-
mercurial.html)) from 2010 would seem to suggest that others had a similar
experience.

------
programminggeek
Because it's awesome?

I personally started using git because github made setting up hosted version
control so darned easy and nice. Also, I hated using SVN from my work life
experience, so I knew I didn't want to use that on my own projects.

Once I understood the power of git branching there is no way I could ever go
back. Also, I tried mercurial and it always felt slower and "worse". Git
commands might be cryptic, but it's always felt faster and had a community
around it that makes better tools for it.

------
wiremine
I remember attending an OSCON session on git vs. Subversion back in 2006 or
2007. The presenter's thesis was basically that git was more efficient than
subversion when it came to branching.

Near the end he walked through the distributed nature of git. That was the
second of third OSCON I attended, and I have never seen, nor have I seen
since, that many utterly confused developers in a single room.

At the time I thought it was just a poor presentation.

With the benefit of hindsight, I've realized the presentation was just fine.
We, the developers, just had that much baggage from using CSV and Subversion.
"What do you mean forking isn't evil!" "What do you mean you can branch like
that?"

It feels like, at some point, there was a tipping point of younger developers
who didn't have to unlearn subversion. Makes me wonder what other heresies
we'll do a 180 degree turn on in the future...

~~~
freework
Hopefully, test driven development will be one of them. I don't know what will
replace it, but some day we'll look back and say "I can'r believe we used to
spend so much time writing so many tests"

~~~
npsimons
If you don't test it, how do you know it works?

~~~
pestaa
It compiles.

~~~
andyzweb
I like you

------
wmitty
A network effect applies to revision control systems.

Mercurial is a much better fit for how my mind works than Git (I feel that Git
is from the school that thrives despite complexity, where I prefer the school
that puts lots of effort into a really clean model to minimize complexity).

But I am now giving up on Mercurial: every open source project I play with is
on github, so I absolutely need to master Git - and I don't want to keep using
two systems.

The network effect wins.

------
npsimons
I think the question betrays the authors bias and assumes too much; by
claiming that "almost every article comparing mercurial and git" and saying
"it seems like Mercurial has a better command line UX", the author is
obviously a fan of Mercurial; neither of those points seem to be true. While I
can understand the sour grapes at seeing an "inferior" technology win, it's
not that clear cut. I haven't used Mercurial enough to really compare, but I
can say that most of the supposed "advantages" of Mercurial versus Git seem
moot to me. The CLI "UX" differences are negligible, it doesn't matter what
languages they are written in, and git is ultimately more flexible due to less
dogmatism.

Perhaps the question should be closed with an "already answered" link to this:
[http://stackoverflow.com/questions/1598759/git-and-
mercurial...](http://stackoverflow.com/questions/1598759/git-and-mercurial-
compare-and-contrast)

Edit: Followup with some more links:

<http://schacon.github.com/2008/11/24/on-mercurial.html>

<http://tomayko.com/writings/the-thing-about-git>

<http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/>

~~~
Niten
I use both extensively (git for most personal projects, Mercurial at work), so
I feel like chiming in here.

I really do think that Mercurial's user interface is easier for beginners to
pick up, and more difficult to shoot oneself in the foot with. It's the little
things, like the fact that Mercurial's push and pull commands do exactly the
opposite of one another, that hg clone/pull URLs are identical to what you
type into a web browser to browse the repo, and the ease of dealing with
Mercurial "bare" repositories (hg up -r null) for mirroring and backup
purposes.

And the way Mercurial's command-line interface strongly discourages one from
modifying history; it makes it harder for things to get messed up on a small
team coordinating with a shared-access repo. Yes, I know git has the reflog,
but in general people seem to have _much_ fewer "OMG WHAT JUST HAPPENED TO MY
BRANCH" moments with Mercurial than with git. That (along with mq, which
provided a unique solution to our team's needs) was the major reason I chose
Mercurial over git at work. If we're going to brandish about the term "UX"
here, then I'd say Mercurial definitely has a better "UX" than git.

But Mercurial has pain points, too. The biggest one, in my opinion, is the way
branches work: Mercurial started out with named branches, which it seems the
community has recognized as a mistake, and has moved to replace with git-style
branches (called "bookmarks" in Mercurial land). These work better, but there
are still some drawbacks: for one thing, Mercurial lacks the notion of a
"remote", so unlike in git your local bookmarks and remote bookmarks have to
share the same namespace. This leads to counter-intuitive behavior when it
comes to synchronizing bookmarks with a remote server, and often you'll find
that bookmarks aren't necessarily updated when you'd expect them to be.

Additionally, the notion of a "tip" makes working with feature branches
frustrating, because by default Mercurial will check out from whatever branch
was pushed to most recently, rather than a de-facto standard "master" as in
git. Hand in hand with this complaint, by default Mercurial will want to push
_all_ your changesets, not just those under your current working bookmark, so
you have to constantly specify e.g. "hg push -r master" to keep from pushing
local throw-away branches. And it's not easy to delete local throw-away
branches if you decide you don't want them (the downside of Mercurials
aversion toward history modification), so one generally winds up using a
separately-cloned repo for temporary work, which is unfortunate in contrast
with git.

Mercurial and git are both great, efficient, high-performance tools. But if I
had to generalize, I'd say that Mercurial is better for beginners and for
"enterprisey" usage, whereas git, despite its interface inconsistencies, can
be more powerful once you fully understand it and its data model (but only if
you aren't working primarily on Windows, and don't need Mercurial Queues).

~~~
alwillis
From what I can see, Mercurial actually has more flexibility when it comes to
branching: [http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-
me...](http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/)

~~~
Niten
More options, certainly, but I find git to be much more painless in this
regard. Mercurial doesn't have anything equivalent to git's convenient
workflow for creating temporary, local throwaway branches, without changing to
a new working directory.

~~~
alwillis
You mean like Mercurial bookmarks?

 _Branching with bookmarks is very close to the way git usually handles
branching. Mercurial bookmarks are like git refs: named pointers to changesets
that move on commit._

~~~
Niten
But like I explained in detail above, using Mercurial bookmarks it is tedious
to avoid pushing your throw-away branch to the main repository, and you can't
simply delete the branch when you're done with it. Git is much superior in
this regard.

------
mcantelon
A blog post from 2010:

[http://blog.extracheese.org/2010/05/why-i-switched-to-git-
fr...](http://blog.extracheese.org/2010/05/why-i-switched-to-git-from-
mercurial.html)

Concludes that Git handles larger amounts of data more efficiently and stores
revision info in a safer/clearer way. Git might be more arcane in terms of
it's command syntax, but gets the job done.

------
calinet6
A classic case of critical mass. Linus started git, then Github made it
social, then everyone started using git, so you did too.

Think of it exactly like an atomic bomb. Atomic bombs are simple: you need
fissile material that decays and emits neutrons, and you need it to get close
enough to keep a reaction going.

The fissile material in this case is the quality of the software. If it's
good, consider it fissile. If it sucks, it probably ain't exploding anytime
soon. Git is good. It works, it's fun to use, and it's collaborative.

The trigger was Linux. A large developer community suddenly was introduced to
it, and used it day-to-day as Linus was still developing Git itself. The bomb
had dropped.

Github was the mechanism itself. It brought all of the developers closer
together (like neutrons) and the reaction started spreading. The quality of
the experience ensured people actually wanted to be there, and to share it.

Critical mass of ~the social web~ anything in society. 1. Quality, 2. Trigger,
3. Social Mechanism. Boom.

------
_jb
I don't know when that was, but at some point the rails (sexy) community
pushed for git. That sure helped.

Edit: no pun intended ;)

~~~
lylejohnson
I agree that the Rails halo effect probably had a lot to do with it. That's
certainly where I first heard about it.

------
drue
Popularity begets popularity. I evaluated a ClearCase replacement in early
2012 for a large company, and Git is clearly the "nobody ever got fired for
buying IBM" SCM.

I looked at hg. It is easier, especially for the windows users. However, git
was already coming from a few different directions and hg's simplicity was not
enough to tip the scale.

We are now mid-migration. If git devs are listening - this is my biggest nit:

$ apropos git | grep ^git | wc -l 159

I do believe an alternative "porcelain" will eventually supplant the core git
commands, making it more user friendly.

------
Too
I think the data source is a bit flawed - _"Nr of packages installed on
debian"_

I would say mercurial is more polished on windows, taking tortoisehg into
account. Maybe most mercurial users are on windows while most git users are on
linux?

(now i don't believe that mercurial actually is bigger than git, even on
windows, but the data from the post is still dodgy)

The _"Linux uses git!"_ -argument is a good one but mercurial has an almost as
good one: Firefox. So i don't think that would be an overwhelming factor.

------
cdibona
The uptick in 2010 has a lot to do with the introduction of git over http
solidifying and I firmly believe that android's use of git, which is extensive
and that reliance on git coupled with the rise of the platform pulled an
incredible number of developers onto Git and over the learning hump.

If you can find the 'open source updates' from oscon on youtube/oreilly, Shawn
Pearce gives an architectural update that will inform your speculations.

------
rjzzleep
am i the only who's thinking it is a nice real world solution to a real world
problem?

~~~
npsimons
No, that's precisely the feeling I get every time I see an
article/comment/blog post saying something along the lines of "why is git
winning? Mercurial is superior because it's easier to use, won't let you
change history, and it's written in Python!"

------
robodale
Shut up about the tools you use and write some damn code.
[http://importantshock.wordpress.com/2008/08/07/git-vs-
mercur...](http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/)

~~~
alwillis
I like this one better: Git is Wesley Snipes, Mercurial is Denzel Washington:
<http://www.ericsink.com/entries/hg_denzel.html>

------
jiggy2011
I wonder how much of the time git is in practice used identically to SVN?

~~~
jlgreco
Even used like that, there are clear advantages to using git to preform that
model rather than SVN. To really get the proper "just like SVN" experience you
would have to find a way to make git suck at branches and merging, at the
least.

~~~
jiggy2011
I never found actually doing branches and merges in SVN any more difficult
than git, not sure what the big differences are?

OTOH not having to do the merges on the shared repo is much better and avoids
the "don't checkout HEAD just yet 'cos it's all manor of fucked up right now"
problem.

~~~
jlgreco
It is obviously a hard thing to quantify, but relative pain of branching and
merging is apparent through the different version control styles commonly
advocated/actually seen for both systems. As a simple example, while this
(<http://nvie.com/posts/a-successful-git-branching-model/>) is certainly
possible in SVN, I have never actually seen an SVN shop consistently doing
that. To the extent that any I have seen do follow that model, they do so
essentially at gunpoint, not because it is a pleasant thing to do. On the
other hand that sort of thing is exceedingly simple and _pleasant_ in git. As
a consequence, in the real world, people are much more willing to employ both
with git without any hesitation at all.

Also poorly quantifiable is the sense of fear or anticipation that courses
through your veins when you hear the phrase, in an SVN shop, _"Hey, I've got a
feature branch I want to merge in."_

------
cllns
"Git... literally exploded." :)

------
ngyt
Because github is backed by $100+ million of venture capital and they have
been virally marketing their tool.

------
lifeguard
Because hackers said bitkeeper sucked.

------
camus
because git is easy , git is distributed , and github is fancy. My designer
team use git yet they cant program. They learned basic git in 4 hours. SVN is
much more complicated to work with and to learn for non developers. Mercurial
is cool too ,but since most of the library we use are on github my
organisation push on github ( and bitbucket ).

