Why did Git become so popular?(programmers.stackexchange.com)
programmers.stackexchange.com
Why did Git become so popular?
http://programmers.stackexchange.com/q/177875/5940
23 comments
Shut up about the tools you use and write some damn code.
http://importantshock.wordpress.com/2008/08/07/git-vs-mercur...
I like this one better: Git is Wesley Snipes, Mercurial is Denzel Washington: http://www.ericsink.com/entries/hg_denzel.html
I wonder how much of the time git is in practice used identically to SVN?
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.
And then make add-commit-push a single operation.
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.
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.
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."
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."
Once you do a feature branch... you never go back.
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.
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.
As a single data point, I chose git due to github around late 2010 and consequently moved a couple of my clients (and current employer) over to git/hub.
I personally still prefer bzr's cli.
I personally still prefer bzr's cli.
Or, from another perspective, "Linux uses it, so we should too!"
No one ever got fired for going with Linus ;-)
GitHub was founded in 2008. The spike is in 2010-01. That's what the question mentions too.
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.
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.
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.
that is what network effects look like
for eg. it is comparable to the chart of Facebook growth[0]
[0] http://www.nathaninfocus.com/wp-content/uploads/2011/01/Face...
for eg. it is comparable to the chart of Facebook growth[0]
[0] http://www.nathaninfocus.com/wp-content/uploads/2011/01/Face...
> Just to make clear, this graph show the installation of git on debian systems. Around the time the spike happens the Debian package was renamed from git-core to git. Maybe people found the package easier now that the name reflected the software.
http://programmers.stackexchange.com/a/177892
Actually the spike is in 2010-04. I don't know that it's really related, but Drupal began switching from CVS to Git in 2010-03. I know a lot of people (myself included) looked at Git for the first time because of that.
Before that time, git lacked http support, which means a large population behind firewalls couldn't use it. From memory, that happened sometime in December 2009, which correlates very closely with that graph.
I wonder how big a factor Windows is. I remember that in 200x several projects (e.g. Mozilla and Java) chose Mercurial over Git because of Git's poor Windows support. At which point did Git become usable on Windows?
My first encounter with git was in about 2009 on windows, and I don't recall it being unusable.
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)
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.
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.
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.
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.
Exactly. Stupid is better. Stupid doesn't break. I like stupid things which I understand in and out. Yes, git command line is not the best but because I understand the data format so well, you can easily use different approaches to solve a given problem.
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.
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.
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.
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.
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.
Of course, I may also be a terrible teacher.
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.
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.
Sure, I was talking about my situation.
And of course, if mercurial could give me more features, I'd probably think twice. However, it's practically equivalent to git.
I was comparing git and mercurial, not giving the one true testament to comparison of every possible version control system.
And of course, if mercurial could give me more features, I'd probably think twice. However, it's practically equivalent to git.
I was comparing git and mercurial, not giving the one true testament to comparison of every possible version control system.
This seems a little exaggerated.
Before git took over there were all kinds of VCS in use including a bunch of proprietary stuff.
If most of your work is done with one group of people inside your company and you decide mercurial is a better fit it would seem silly just to go with git because it is popular.
Besides the two are similar enough that someone versed in mercurial should be able to learn enough git to be useful quickly enough should it be required.
If most of your work is done with one group of people inside your company and you decide mercurial is a better fit it would seem silly just to go with git because it is popular.
Besides the two are similar enough that someone versed in mercurial should be able to learn enough git to be useful quickly enough should it be required.
No, before git took over there was CVS (and a brief moment when svn looked like it might win, before being forgotten). There still are "all kinds of VCS including a bunch of proprietary stuff". But as before with CVS (and RCS before it) the open source community has picked an overwhelming favorite.
And I'm not saying you should choose git because it's better. I'm saying git "won" in the community because it was the choice of people who want to play in the community. Culture matters, and hg's proponents, for whatever reason, are less likely to want to share their stuff.
And I'm not saying you should choose git because it's better. I'm saying git "won" in the community because it was the choice of people who want to play in the community. Culture matters, and hg's proponents, for whatever reason, are less likely to want to share their stuff.
Well I remember MS Sourcesafe being popular a few years ago.
Do hg people "share less" or are there simply less of them? IIRC github allows commits from hg as well as git.
And of course not everyone (in fact possibly only the minority) is interested in cloning and issuing pull requests on OSS a huge amount of programming happens internally in corporations where everyone will use whichever VCS is mandated.
Do hg people "share less" or are there simply less of them? IIRC github allows commits from hg as well as git.
And of course not everyone (in fact possibly only the minority) is interested in cloning and issuing pull requests on OSS a huge amount of programming happens internally in corporations where everyone will use whichever VCS is mandated.
I'd like to know your grounds for saying svn was "forgotten". Forgotten by who?
Subversion is used by very few remaining public projects, almost entirely for legacy reasons. Almost literally zero "recent" projects are using it at all. It has no more mind share than does CVS at this point, and "no one" uses CVS (again, except for a few legacy spots). I really didn't think that was controversial.
Subversion was indeed a much better CVS than CVS. And the world almost jumped on it as a standard. But then git appeared. If you were a young person looking at building exciting projects from source, you might never have reason to learn svn. I think that qualifies as "forgotten"
Subversion was indeed a much better CVS than CVS. And the world almost jumped on it as a standard. But then git appeared. If you were a young person looking at building exciting projects from source, you might never have reason to learn svn. I think that qualifies as "forgotten"
I think we're at odds because I'm thinking of developers in general and you are focused on open source work. I don't have stats, but I'd be willing to bet that a majority of code being written is closed source even today. I think this is worth remembering in any discussion about source control.
I'm willing to bet there's plenty of small PHP shops out there still using SVN.
So you "know" "Mercurial people", yet speak of others as coming from an "ivory tower"? Given that you seem to be in possession of special knowledge, why don't you tell us precisely what "SCM is for"?
As I said, I worked with Git. I am no longer interested in it as a solution. I'm not sure why I (or any programmer) would need to 'get excited' to learn Git. It's pretty easy to understand.
Unnecessarily harsh response to a good point.
Network effect: many many people pick git because everyone else uses it (and that’s a good reason), thus they never try Mercurial, which may or may not be better suited to their use case.
Network effect: many many people pick git because everyone else uses it (and that’s a good reason), thus they never try Mercurial, which may or may not be better suited to their use case.
[deleted](3)
>Using it in your own ivory tower isn't going to impress anyone for the simple reason that no one sees it
Using loaded terms to put down people who use the tool they prefer isn't going to convince anyone that your argument has merit.
Using loaded terms to put down people who use the tool they prefer isn't going to convince anyone that your argument has merit.
Making style points about bland, cliched[1] metaphors adds even less to the discussion. Seriously? "Ivory Tower" (!) is a forbidden term that should be banned from civil discourse?
[1] Now that you've drawn attention to it, I do indeed wish I'd phrased that differently. But certainly not because I hurt someone's feelings...
[1] Now that you've drawn attention to it, I do indeed wish I'd phrased that differently. But certainly not because I hurt someone's feelings...
Who said it was forbidden? Or that you hurt anyone's feelings? Your argument is less effective due to the words you used. That is what I said.
To be fair, BitBucket was way uglier than GitHub until very recently (latest redesign). That's a turn-off for most people (unfortunately).
The new BitBucket is awesome, though.
The new BitBucket is awesome, though.
Clean design inspires confidence. I looked at BitBucket about 2 years ago, and just didn't have enough confidence in it, but recently created quite a few repo's on it and am using them everyday. The new re-design makes all the difference in gaining my trust.
At least that's how I see it.
At least that's how I see it.
I agree with you. Even though BitBucket allowed private repositories for free, their poor usability and interface kept users away. GitHub is not just Git. GitHub would have become popular due to its ease of use and cool user interface even if it was based on Mercurial (hg) or, may be, even Darcs. Bitbucket's latest design is good but has arrived later than expected.
Definitely. I remember checking out the BitBucket repo for pygments a while back and noticing how clunky the ui was compared to github. The new redesign at a glance seems like a huge improvement.
Agreed! BitBucket's [http://bitbucket.org/] new UI rocks!
I have used Mercurial extensively, and I while I find its interface superior to git, I find that git actually models the kind of development I do.
Also, git is accumulating tooling and integration with other tools much more than hg is, afaict.
Also, git is accumulating tooling and integration with other tools much more than hg is, afaict.
BitBucket is not even close to being as popular as GitHub, and it's not as nice for just browsing around, so the network effect is against it: you don't put code on BitBucket to be seen really.
Free private repos are great, of course.
Free private repos are great, of course.
> I would have to say it's because not enough people have
> tried Mercurial
I switched to hg, found it very much the same as git, no appreciable difference to warrant moving again.
code control is a solved problem and people have moved on to do other things...
code control is a solved problem and people have moved on to do other things...
[deleted]
My personal favorite is Bazaar, but Mercurial is good, too. I also heard very good opinions about darcs, but didn't try it yet.
Mercurial has BitBucket and Bazaar has Launchpad, so they hardly 'loose' to git and GitHub here. There is but one thing that git does better (I'm forced to use git at work) - it's faster, or at least feels faster. Other than that, on the technical side, both Bazaar and Mercurial are I think on par with git and they win hands down in terms of ease of use.
So, yes, I would guess that the cause of git popularity is primarily Linus and then GitHub and then the popularity itself.
Mercurial has BitBucket and Bazaar has Launchpad, so they hardly 'loose' to git and GitHub here. There is but one thing that git does better (I'm forced to use git at work) - it's faster, or at least feels faster. Other than that, on the technical side, both Bazaar and Mercurial are I think on par with git and they win hands down in terms of ease of use.
So, yes, I would guess that the cause of git popularity is primarily Linus and then GitHub and then the popularity itself.
Popularity itself is an often overlooked feature. When trying to sell the use of a version control system to others (peers, coworkers, bosses, etc. Or more difficult if you are trying to make an institutional change) you are already in a better position with git than you are with mercurial.
If all mercurial is bringing to the table is being a bit more pleasant, I am still going to pass over it for that reason.
If all mercurial is bringing to the table is being a bit more pleasant, I am still going to pass over it for that reason.
I can sympathize with the difficulty of persuading others. But consider this not-so-far-fetched example: if you're choosing an open-source database, you would choose MySQL based on popularity instead of PostgreSQL, which I would argue in most cases is a mistake--which you'll likely have to live with for years.
That's not a fair comparison. Mercurial is better than git in certain aspects (mainly command line experience) but git by itself is a solid content tracker. It has an extremely simple data model and it's rock solid. As someone else said in this thread, git has no separate notion of 'branch', 'tag' like Mercurial. In a way, git is actually like PostgreSQL, a solid piece of software which you can trust.
It's more than just command line stuff; Google did an extensive comparison that more people should look at: http://code.google.com/p/support/wiki/DVCSAnalysis
That comparison is over 4 years old. Google code now supports git, and most of the arguments against git are either spurious ("git history isn't sacred!")[1] or have been improved since then (better windows support, smart http protocol, single user-visible binary, etc.).
[1] dvcs history locally should not be sacred, because rewriting experimental branches is necessary for clarity and to avoid polluting the main repository branches. dvcs history on a central repo can be made sacred with git by disabling non-ff commits and disabling deletes.
[1] dvcs history locally should not be sacred, because rewriting experimental branches is necessary for clarity and to avoid polluting the main repository branches. dvcs history on a central repo can be made sacred with git by disabling non-ff commits and disabling deletes.
In addition to the points that solutionyogi raises, I don't think that is a very good comparison when you consider the differences in commercial and private RDBMS', and the differences between commercial centralized VCS and open source DVCS.
DVCS (either mercurial or git) seems to be a much more exotic concept for people unfamiliar with DVCS than MySQL/PostgreSQL is to those only familiar with, say, Oracle RDBMS.
I'm not a DBA though, so maybe I am wildly wrong with that thought.
(Also this comparison maps back to the topic incorrectly, in that I obviously greatly prefer PostgreSQL in the comparison, but I greatly prefer git in the other scenario).
DVCS (either mercurial or git) seems to be a much more exotic concept for people unfamiliar with DVCS than MySQL/PostgreSQL is to those only familiar with, say, Oracle RDBMS.
I'm not a DBA though, so maybe I am wildly wrong with that thought.
(Also this comparison maps back to the topic incorrectly, in that I obviously greatly prefer PostgreSQL in the comparison, but I greatly prefer git in the other scenario).
What do you like about bazaar in contrast to mercurial or git?
I was a big subversion fan until I took a systems programming position where the dev team used Mercurial. It took me a few weeks to really start liking it, but now I absolutely love it. It's great.
Which tool do you prefer the most?
TFS for large scale enterprise, hands-down. But I don't recommend it for small shops. (Expensive, although I know it's free for shops with 5 devs or fewer) simply because code management is easy and you can build automated deployment without having to use anything else (you can script with PowerBuilder, Ant, whatever if you like, though). The issue I've found with that is it's not easy to find people who don't code for a living but understand scripting enough to build automated deployments. I'm also not crazy about TFS' visual displays of branches - ClearCase (which is god-awful in every other way) has the best visual display of code and branches.
Mercurial for anything smaller or startup. Love it. The issue with Mercurial is that you'll need to determine how you want to do automated deploy builds, but the code management is great and using BitBucket + Hg I never have trouble seeing which code I'm working in or resolving conflicts. I actually think Mercurial has the second-best visual branching display.
Mercurial for anything smaller or startup. Love it. The issue with Mercurial is that you'll need to determine how you want to do automated deploy builds, but the code management is great and using BitBucket + Hg I never have trouble seeing which code I'm working in or resolving conflicts. I actually think Mercurial has the second-best visual branching display.
>>TFS for large scale enterprise, hands-down.
Real big enterprise cannot use TFS without being in a mess with merge. You always have to merge to a parent which require a lot of organisation. Also, it's not the fastest source control when the code base is over few gigs per branches. With over 50 developers/testers (in the same project) we had reach a bottleneck with TFS.
Real big enterprise cannot use TFS without being in a mess with merge. You always have to merge to a parent which require a lot of organisation. Also, it's not the fastest source control when the code base is over few gigs per branches. With over 50 developers/testers (in the same project) we had reach a bottleneck with TFS.
We assume ClearCase is the worst, right?
Assuming too much...
People who conplain loudly about ClearCase most often never understood how it is supposed to work. Ok ok, you need an army of administrators to make it work but still far from being the worst.
Sourcesafe?
Sourcesafe?
"most often never understood how it is supposed to work"
This is a BS argument.
Yes, everybody got it wrong, Git is wrong, SVN is wrong, it's CCs broken model that's correct.
" you need an army of administrators to make it work"
Yes, let's sink an awful amount of money in a half-baked software that needs all kinds of 'helpers' to work properly.
Personally I won't work in a company that uses CC anymore, and it's been only bliss since then.
Sourcesafe is bad, but it's a different kind of bad. And it makes even CC look good.
This is a BS argument.
Yes, everybody got it wrong, Git is wrong, SVN is wrong, it's CCs broken model that's correct.
" you need an army of administrators to make it work"
Yes, let's sink an awful amount of money in a half-baked software that needs all kinds of 'helpers' to work properly.
Personally I won't work in a company that uses CC anymore, and it's been only bliss since then.
Sourcesafe is bad, but it's a different kind of bad. And it makes even CC look good.
I don't have any experience of knowledge of Sourcesafe, but it wasn't in the original list ;-)
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 ;)
Edit: no pun intended ;)
I agree that the Rails halo effect probably had a lot to do with it. That's certainly where I first heard about it.
Rails moved to Git in 2008, so I don't think that's it.
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&...
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).
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&...
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).
With a bit of image editing: http://i.imgur.com/PmYj7.png
It does look like something happened that caused a spike in popularity.
It does look like something happened that caused a spike in popularity.
Not as instant, but still exponential. That's an interesting factoid, but I think the intent of the question remains valid.
> 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?
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?
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.
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.
Why it's so important to double check your data.
am i the only who's thinking it is a nice real world solution to a real world problem?
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!"
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.
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.
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 ).
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.
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.
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.
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.
A blog post from 2010:
http://blog.extracheese.org/2010/05/why-i-switched-to-git-fr...
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.
http://blog.extracheese.org/2010/05/why-i-switched-to-git-fr...
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.
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...) from 2010 would seem to suggest that others had a similar experience.
"Git... literally exploded." :)
[deleted]
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...
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/
Perhaps the question should be closed with an "already answered" link to this: http://stackoverflow.com/questions/1598759/git-and-mercurial...
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/
You said you haven't used Mercurial much to really compare, and then you compared, and said git is more flexible, and the CLI difference are negligible. So I think you definitely have a bias towards git.
I use Mercurial and Git every day, and I can tell you there's a marked difference between the usability of Mercurial and Git. Git would become totally unusable if it weren't for stackoverflow and google, while I can figure everything out just from Mercurial's short and sweet help manuals.
I use Mercurial and Git every day, and I can tell you there's a marked difference between the usability of Mercurial and Git. Git would become totally unusable if it weren't for stackoverflow and google, while I can figure everything out just from Mercurial's short and sweet help manuals.
I admit I'm biased towards git; but, unlike the original question poster, I can link to articles backing up my assessment that the UX differences between Git and Mercurial are negligible at best, and most likely any perceived differences are highly subjective.
Actually, the UX differences aren't negligible; from Google's assessment of Mercurial and Git. Complexity has a cost in terms of time, mistakes made, training, that can be quantified. From Google's assessment of Mercurial and Git: http://code.google.com/p/support/wiki/DVCSAnalysis
Learning Curve. Git has a steeper learning curve than Mercurial due to a number of factors. Git has more commands and options, the volume of which can be intimidating to new users. Mercurial's documentation tends to be more complete and easier for novices to read. Mercurial's terminology and commands are also a closer to Subversion and CVS, making it familiar to people migrating from those systems.
Learning Curve. Git has a steeper learning curve than Mercurial due to a number of factors. Git has more commands and options, the volume of which can be intimidating to new users. Mercurial's documentation tends to be more complete and easier for novices to read. Mercurial's terminology and commands are also a closer to Subversion and CVS, making it familiar to people migrating from those systems.
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).
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).
but only if you aren't working primarily on Windows
Again, I'll admit I'm biased (I'm mostly a Linux guy), but for the day job, they are currently paying me to develop stuff for Windows, and both myself (via Cygwin), and my current coding partner (via MSysGit) have no issues whatsoever with Git in Windows. A previous team member also quickly adapted to Git via TortoiseGit.
The flexibility of being able to rewrite history, the staging area, stashes and branching quickly are just too powerful, and being both code monkeys and CLI junkies, we don't miss the "integration" much (albeit, I love EGG: https://github.com/byplayer/egg).
Again, I'll admit I'm biased (I'm mostly a Linux guy), but for the day job, they are currently paying me to develop stuff for Windows, and both myself (via Cygwin), and my current coding partner (via MSysGit) have no issues whatsoever with Git in Windows. A previous team member also quickly adapted to Git via TortoiseGit.
The flexibility of being able to rewrite history, the staging area, stashes and branching quickly are just too powerful, and being both code monkeys and CLI junkies, we don't miss the "integration" much (albeit, I love EGG: https://github.com/byplayer/egg).
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...
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.
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.
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.
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.
Because github is backed by $100+ million of venture capital and they have been virally marketing their tool.
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.
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.
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...
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...
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"
Maybe, but the we'd need incredibly better tools than what we have today. Git was a vastly better tool, which enabled us to reshape the culture around how we managed code. Test-driven development is a culture that lacks git-level tools.
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.
If you can find the 'open source updates' from oscon on youtube/oreilly, Shawn Pearce gives an architectural update that will inform your speculations.
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.
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.