Alson Kemp

GitHub, ‘git’ and the forking fallacy

GitHub is a pretty sweet system. One of the best aspects of web 2.0 has been the focus on simple, straightforward web app usability/utility.  GitHub is a great example of some of web 2.0′s best attributes: a really interesting model coupled with straightforward usability and just a touch of AJAX.  I never would have tried Git without GitHub.

Git is pretty interesting, too. Turns out that git is effective at encouraging social involvement in coding. The Turbinado project has been forked a few times… ‘Forked’?! Wait! That’s what happens when projects are in deep trouble, right?!

Maybe so, but not necessarily in git. Since git is a decentralized revision control system (like our beloved darcs), ‘forking’ is roughly equivalent to ‘checking out’. A ‘fork’ is a good thing, so Rails’ fork count (398) is heroic.

Written by alson

December 18th, 2008 at 1:04 am

with 3 comments

3 Responses to 'GitHub, ‘git’ and the forking fallacy'

Subscribe to comments with RSS or TrackBack to 'GitHub, ‘git’ and the forking fallacy'.

  1. Indeed, I think the idea is that one forks a project and then later asks the original developer to merge the branch or pull the patches into their branch. This is Distributed development™!

    Chris Done

    18 Dec 08 at 3:20 am

  2. Actually, I think it may be worse than that. I believe GitHub (and Gitorius?) is probably the only reason alternative DVCS (including darcs) will not win over Git for in the current generation of DVCS.

    On the point of forking however, is it also possible that we’re still not actually forking at all!? It seems to me that a fork in a DVCS is actually closer to a checkout in centralized systems, with the added benefits of full VCS capabilities locally. The term forking appears to be more of a sentimental rebuttal to the popularity of centralized VCS rather than an actual ‘fork’ of a project, even accounting for the greater ease in forking the code base if that was someone’s goal.

    My thinking here comes from books like Karl Fogel’s “Producing Open Source Software,” and more specifically the section dedicated to forks in chapter 8 (http://producingoss.com/en/forks.html). Using this definition, while a fork is still technically a checkout of the code base, it has properties closer to a completely separate project without the direct intent of re-merging later on (although there can still be cooperation between them.)

    – Lorenz

  3. Lorenz,

    Agreed. “Clothes make the man” and users + tools make the DVCS. These “network effects” gave us Windows’ dominance and will probably hand git the DVCS crown… git’s kind of a pain to use, but I’m not as dogmatic about DVCSs as I am about programming languages, so I’ll just follow the leader.

    Agreed on “forking”, too. It would have been good if another term were used for cloning a repo. “Fork” has a ton of baggage. A “forked” repo is really more like a child of the parent repo: might be very similar to or different than the parent, but is definitely derived from the parent. Maybe “Create Child”? Gitorious uses “clone” (which follows git).



    22 Dec 08 at 3:03 pm

Leave a Reply