The Rise of Git

snydeq writes "InfoWorld takes a look at the rise of Git, the use of which has increased sixfold in the past three years. Buoyed in large part by interest among the Ruby community and younger developers, Git has been gaining share for open source development largely because of its distributed architecture, analysts note. And the version control system stands to gain further traction on Subversion in the years ahead, as Eclipse is making Git its preferred version control system, a move inspired by developers and members."

Comments

Bazaar

[mgiuca]

Yet another DVCS article that doesn't mention Bazaar at all. And cursorily swats away Mercurial as "not as large a community."

It seems like just about every argument in favour of Git could be equally applied to any other DVCS. On top of that, the only thing it has going for it is a larger community (and being the creation of Torvalds).

I've argued to wit's end that Bazaar is superior to Git in a multitude of ways (branches as separate file-system directories, optional ability to work in bound mode as with Subversion, revision numbers, explicit notion of a 'trunk' versus merged branches, explicit moves/renames rather than heuristics, commit metadata). Basically Bazaar has a much richer data structure than Git. The last point (commit metadata) is crucial: because Git lacks commit metadata, it is impossible to meaningfully use any other revision control system in conjunction with Git -- what a selfish decision.

Yet all I ever hear is "Git is better than all the other revision control systems because [generic reasons why DVCSes are better than centralised ones]." Such is the case with Scott Chacon's site Why Git is Better Than X, which I wrote a rebuttal of at Why Git Ain't Better Than X.

Re:Github?

[mgiuca]

Well that's really what GitHub is ... much like Facebook treats every "object" (status update, photo, event) as a commentable, likable object, so does GitHub for VCS objects such as commits.

It's quite funny to see a commit with a comment thread attached to it. I saw one that went viral and ended up with 88 comments including meme images.

Data, Images, Binary builds etc.

[syousef]

Exactly who the fuck has 50GB in one source code tree?

--
BMO

Those who store data, images, other binaries like built executables and other artifacts alongside the code.

You can argue that you shouldn't do that, but there are times when it's difficult to avoid, and if you need to be able to keep versions, it can be done easily with something like SVN.

I think GIT has it's advantages, but to reject all predcessors and raise it up as the only way to go is foolish.

PostgreSQL CVS-git conversion

[greg1104]

I had a small role in getting the PostgreSQL project to convert from CVS to git. There's a good summary of what happened at Lessons from PostgreSQL's Git transition. With a pretty conservative development community, the bar for converting from CVS to git was set pretty high: the entire CVS repository had to come through, such that every single release ever tagged could be checked out and get exactly the same files as checking it out of CVS (a little binary diff tool was used to confirm). With around 15 years of history in there, that took some upstream fixes to the cvs2git tool to finally accomplish; it took just over a year to work out all the details to everyone's satisfaction. My checked out copy of the current repo is 272MB right now, so neither small nor giant.

I would say that everyone who works regularly on the code is at least a little bit more productive than they used to be, with the older CVS experts having seen the least such improvement. But some people are a whole lot more productive. I'd put myself in that category--my patch contribution rate is way up now that it's so much easier to pop out a branch to hack on some small thing and then submit the result for review.

And the conversion seems to have improved the uptake of new developers getting involved in working on the code. Having to deal with CVS was a major drag for younger developers in particular, and Subversion is equally foreign to most of them now. As suggested in the article, anyone under 25 will only touch a corporate style CVS or Subversion repo if dragged kicking and screaming into it. As more of that generation rises through IT, old style repos will continue to get shredded at a good rate every year. It could have been any of the DVCS systems that ended up in this position, but git was the one that got the right balance of feature, innovation rate, and publicity. Now that it's got such a wide user base, too, I don't see any of the other VCS software options competing with it successfully in the near future.

Re:Mercurial

[euroq]

Mercurial's most touted advantage is that it's easier to learn, but this is a joke. If you develop, you interact with the version control system all day. A tiny advantage in learning it faster is nothing compared to not being able what you want to do afterwards, or having to redo something because the version control works against you instead of with you.

I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times. What I quoted is an okay argument at a personal level. However, there is something to be said as an organization that having an easy-to-use tools is better.

I am not making the argument that either Mercurial or Git is better; I am making the argument that tools which are easier to use will lead to less fuck-ups in an organization.

Re:It's because

[buchner.johannes]

see "git clone --depth"