Git is exploding | Hacker News Reader

Git is exploding

qa.debian.org

199 pointsdavvid65 comments

"bazaar" should be "bzr".

It's important to note that this graph is generated with data collected from people who have the popularity-content Debian package installed [1]. The "vote" metric it provides is probably a more accurate method for comparing which of the packages are in active use (it records accesses of the package's binaries in the last 30 days).

[1]: http://popcon.debian.org/

I actually heard this: "Linus Torvalds, the creator of Git". That's like saying "George Lucas, director of American Graffiti".

I dunno, git spawned a revolution in how we think of version control (even mercurial came out of the initial discussions of git); that's a pretty big deal.

Mercurial and Git shipped at about the same time. It's not fair to say Git inspired Mercurial.

Both git and mercurial arose out of discussions on the linux kernel mailing list related to a replacement for BitKeeper. (E.g. cf. http://lkml.indiana.edu/hypermail/linux/kernel/0504.3/1404.h...)

Distributed version control existed long before git, and any monotone enthusiast will tell you Torvalds got it wrong.

Care to explain how Linus got it wrong? I've never used Monotone, but searching the web I could't find a single thing in which Monotone was better than Git (although I did find information of the opposite kind).

Monotone got the user experience right. The git interface simply exposes the atomic operations of commit-tree management. Monotone, on the other hand, provides an abstraction on top of that which maps quite well to how people actually use a DCVS. Doing anything more than the standard edit-commit-fetch-merge-push cycle on git is like casting an arcane spell. The equivalent operation on monotone is either a) nothing, because monotone automatically handles that high-level operation for you, or b) intuitively obvious and simple to construct.

More fundamentally, monotone records both manifest and diff history, which from the git point of view is entirely redundant. However it allows monotone to do much more sophisticated merge handling than out-of-the-box git, and better captures the human intent of a changeset. It allows monotone to correctly handle copy operations, for example, which is relevant in the context of history-rewriting operations.

Fair point. How about, git spawned a revolution in how the masses think of version control?

I've never used monotone, but my vague impression is it was indeed influential / ahead of its time, but didn't have enough of a focus on performance to really catch on. But that's totally uniformed speculation on my part :)

(And certainly kernels existed long before Linux... ;)

That is a fair assessment of monotone, both in terms of influence and performance, although recent releases have gotten better now that there are a few select large projects that use it (Pidgin, primarily).

Monotone uses a sqlite relational database for the code repository, with built-in synchronization/replication. It uses a PGP-like PKI and digital signature system for its trust rules (allowing for a trust-less store-and-forward architecture that still none of the other DCVS systems support). It redundantly stores both revision history and content diff views (two equivalent ways of serializing DCVS trees), and automatically keeps the two synchronized. It is extremely smart about merging and branch handling (the monotone-dev list is wonderful place to find analysis of edge-case merge behvior). And it did all of this back in early 2003.

Monotone was ahead of its time. It's only “problem” was that its core developers chose to focus on correctness and user interface over optimization, delaying work on performance and scalability until such work would actually be needed... which was much sooner than they expected. Linux was orders of magnitude larger than anything that had been done with monotone at the time. This may be an urban legend, but I've heard it said that ‘git’, the ‘stupid version control system’ was named such in part because it was a grotesque simplification of monotone's sophisticated framework, which Linus Torvalds did hold in high regard.

Monotone is the Lisp of distributed version control... venerable and unsurpassed by anything that followed, but utterly irrelevant today.

Performance was the primary reason Torvalds chose not to use Monotone: i.e. it was too slow for large projects.

To be fair it's more like George Lucas, director of Star Wars ep. 1 if we are going chronologically.

Let's be fair to Git. It's more like George Lucas, producer of Raiders of the Lost Ark.

George Lucas, founder of Industrial Light and Magic.

It was Sun who created Jar Jar.

I took the suggestions and re-made the graph: bazaar -> bzr, git-core added, and only votes used.

http://qa.debian.org/popcon-graph.php?packages=subversion+gi...

Can someone offer an explanation as to the sudden explosion in git's popularity in early 2010?

I think it's partly an artifact: due to a naming conflict, the git package in Debian used to be named "git-core" and was renamed "git" around then.

Looks like that might be the case, if you combine the graphs of git-core and git, you get a roughly-exponential growth shape:

http://qa.debian.org/popcon-graph.php?packages=git+git-core&...

http://qa.debian.org/popcon-graph.php?packages=git++git-core...

With CVS, darcs, monotone also interesting.

I keep tacking RCS onto the ends of these, too :) It keeps surprising me - Mercurial passed RCS ~ last June, and Bazaar passed it in roughly June of this year. It gets a lot of usage still.

I use it pretty often for casual alteration of configuration files.

Why do you prefer it to git or hg for this use case?

This whole article has been rendered silly based on this observation. Yes git's popularity has increased and passed subversion but it was a long time coming and not an explosion at all.

I'd imagine that many projects moving to Gitorious/GitHub as opposed to, say, SourceForge has a role here. According to Wikipedia GitHub gained 1 million new repositories between July 2010 and April 2011. Sourceforge currently has some 300k projects. Not completely an apples to apples comparison but I'd think it gets the general idea. Technically, Git lends itself to "social coding" much better than SVN IMO.

Also, last time I checked, SourceForge has an application process involved in establishing a repository, while Github is just "register and create as many as you like"

With many interesting open source projects migrating to or being started on GitHub, almost everyone depending on such tools will install Git for client usage.

It doesn't necessarily mean Git is that rapidly surpassing SVN in actual use as repository, that is likely to happen way slower than the growth of the install base.

Every use of git is a repository, it's the nature of the distributed beast. In fact I would argue the opposite, git probably has a few orders of magnitude the number of repositories than svn does; even the servers I use for production deployments have 10s of git repositories on them.

I wonder if some popular Debian package happened to specify git as a package dependency, thus installing git for people who did not actually use it?

In a few cases; gettext recommends autopoint, which depends on git, so it will be installed automatically if someone installs gettext.

A few packages depend on gettext that I wouldn't have expected, like blender. This might be a mistake, but anyone who installs Blender will also install git, without ever using it.

Positive network externalities: the more people who use it, the more valuable it is, which creates more incentives to use it yourself.

GitHub?

not likely. see http://siteanalytics.compete.com/github.com/ and http://www.google.com/trends?q=git%2C+mercurial%2C+svn%2C+gi...

Another explanation could be that some packages started having Git as a requirement or dependency. I seem to remember there used to be a package related to the KDE desktop that required the SVN client. I'm not saying Git isn't becoming increasingly popular, but strange jumps might be explained by dependencies or renames, too.

The "vote" metric measures actual use, not just installs.

See the bottom of this page: http://popcon.debian.org/

Mercurial can be installed as a python package, but git is almost always installed as a OS package.

I am looking forward to seeing a graph of gnome3/kde/awesome/xmonad a couple of months after gnome3 hits testing.

Throw in XFCE in that list for those missing Gnome 2 and can't stand Gnome 3 nor Unity.

That was kind of the point...

I'm one of them ;)

I'd like to suggest that git growth, enhanced by the network effect of github, might also be down to the the ease of entry into using version control provided by the excellent freely available documentation and tutorials.

I'm a one man team, by no means a guru but a competent coder, and git was the first version control system where I could make it past the documentation and get to actually using it day to day. I knew I should be using something, git was the something that made learning and implementing it very low cost.

Git's growing popularity is not an artifact of some packaging decisions by Debian. See Google insights for search: http://www.google.com/insights/search/#cat=0-5&q=git%2Cs...

As a ratio, subversion has more people who use it recently than git does. Interesting, you would think that if people were using git, they would be using it much more frequently than subversion (due to local commits).

"votes" is not a count of the number of uses, just that it has been used at least once in the last 30 days.

So someone who frankly hates git and just uses it to clone a repo someone else made with git, while keeping all their own code in other systems, will be measured as 'voting for' git.

Personally, I think both git and hg are broken in different ways, but either still beats svn. Why do git users (as it seems to me) constantly evangelize their product over all others?

That doesn't sound weird: If you're happy with a tool, you will tell people to try it and be happy with it too.

I wonder how many people use git primarily for "git clone <github url>" and that's about it?

I have to admit we still use svn at work (although I've started using git at home on personal stuff) but at the moment the most frequent task I use git for is still simply cloning stuff from github.

At work, before we switched to Git, I used the git-svn bridge. It feels kind of hackish, svn-externals don't work and working with remote branches is doable but you have to be careful when merging ... that being said, I did extensive work with local/remote branches with git-svn and I never saw anybody actually branching / merging in SVN.

I would never go back to SVN. And this is not a zealot-thing in which I'm stating an opinion to protect an investment -- Git is so much better that it isn't even funny.

I agree I prefer git (and also agree that 99% of svn usage in our environment doesn't involve any merging), I think it's just that svn is filling our need for a remote backup/storage for the source code so we're sticking with that for now.

That said we are a very small team and all in the same office so it hasn't been an issue.

I suspect we will slowly start moving new projects over to git though.

Git is so much better that it isn't even funny.

To this day, I've yet to hear an argument for git's superiority that wasn't predicated on:

- The assumption that hiding your work in a local branch is somehow a general feature instead of being detrimental to communication and optimized for Linux's development model, or

- Based on a 2003-era understanding of SVN and its support for merge tracking, branch switching, etc.

I keep hearing a lot of enthusiasm but not much to back it up. Do you have a different take than the above?

We use svn at work too, but pretty much all developers have switched to git-svn.

People used to working with tortoise or versions for mac still use vanilla svn, which is a big reason of why it's kept around.

I wonder where TFS would be on this graph. Not that I think it competes well on merit with these others, but it still has some market forces pushing in its favor. It would be interesting to know how it compares.

TFS would not even be a blip on this graph;)

Assuming tfs is not toyota financing services it appears tfs is microsoft's souce code management system and therefore is most likely not going to show up on debian's popcon.

This is just a guess, but I get the feeling their market share is probably not too large. We use it at my current job, and I actually enjoy using it. The integration build system combined with work item tracking and testing is nice if you have the ability to tailor your companies workflow to the "TFS way" (we are only partially there, still tracking bugs in our legacy intranet site). That said, it truly is a beast to setup/configure/maintain, to the point where I can't imagine any small MS shop bothering (esp. ones w/o a partner license and decent inhouse servers and possibly a build/deployment guy).

My last employer was still on sourcesafe (shudder!) when I left last year, and I'd bet they'll eventually go with something from SourceGear or Seapine before heading down the TFS path.

I think you might need a semilog-y scale to be able to see it.

TFS?

https://en.wikipedia.org/wiki/Team_Foundation_Server

indeed.com's Job Trends shows Subversion still king, Git growing, and Mercurial holding its own.

Subversion, Git, Mercurial Job Trends http://www.indeed.com/jobtrends?q=Subversion%2C+Git%2C+Mercu...

Where could I get ahold of the stats tables used to generate these graphs?

All the links are on Debian popularity contest front page: http://popcon.debian.org/

i <3 gnuplot

I don't think this is an accurate representation of what is going on because market share is not being taken from the others.

pretty sure any developer is likely to have several of these installed; I know I've needed to install them to pull stuff from various open source repositories, regardless of the fact I use git for personal projects

Indeed. E.g., I am using git for more projects than I use mercurial. To these projects, however, I just submitted a limited number of change sets. Most heavily I am using mercurial instead, which I also would choose for future projects. Maybe it would more accurate to measure the number of submissions per time interval.

thanks lt, all and github

Reply on news.ycombinator.com