Skip to content

You keep using that word “distributed”…

People keep telling me that GitHub is the “killer app” of git. Perhaps they meant “productivity killer”?

I submit to you that if your distributed version control workflow has a single point of failure that can bring your work to a crashing halt, you haven’t grokked distributed version control.

I’ve been watching with some concern as more and more people have adopted git, not so much on technical merits, but on the simple fact that GitHub exists. Don’t get me wrong – GitHub is a terrific service which set a new bar in usability for managed source control hosting. But by focusing on GitHub, it seems like the focus has moved away from the distributed nature of git and right back to an SVN-style centralized model (albeit one with easier branching). Today’s wailing and gnashing of teeth reaction to GitHub downtime seems to confirm this trend.

Perhaps it has something to do with the fact that git makes hosting your own public repository absurdly complicated compared to other tools.

Whatever it is, I hope GitHub users take this opportunity to take a keener interest in the D in DVCS.

This was written by avdi. Posted on Wednesday, October 8, 2008, at 11:53 am. Filed under Uncategorized. Bookmark the permalink. Follow comments here with the RSS feed. Post a comment or leave a trackback.

Viewing 7 Comments

    • ^
    • v
    Nice post, we are planning to move to git soon. Right now when we deploy all the code is sucked out of a public repro, I assume that was a problem most users were experiencing. It would suck to have to go to all our machines and tell them hit up an alternative repo. Any thoughts on how to be avoid that using the distributed nature of git?
    • ^
    • v
    I completely agree. I'm trying to find out why people think they need GitHub when it's down for anything other than fresh public clones.

    We've advertised our Disaster Recovery Guide (http://github.com/blog/175-github-disaster-guide) a few times, but I think not enough people know about it. You can still share and deploy GitHub-based repos when the site is down - that's one of the joys of distributed version control.
    • ^
    • v
    I think that the important point here is that GitHub was down, but everyone reasonably expected that it would be back up within a short period. Given that, the effort involved in modding your workflow to not use GitHub wasn't worth the benefit over waiting an hour or two.
    • ^
    • v
    I suggest GitTorrent

    (er I suggest that somebody design and implement it)
    • ^
    • v
    I completely agree. I think its funny how people focus everything around github. For example the one tweet that says "now i'm manually changing code on a live production site" should never be using his github git repo as a dependency for deploying to his production site. If anything he should set up (even if its difficult, 5 minutes save you a ton of pain) a publically accessible git repo either on his computer or some other server which his deployment can depend on.

    And even if that goes down, since everyone who has the repo has the ENTIRE repo, you can just point your deployment scripts to the new repo and hurrah it works.

    My company uses an internal git server for hosting all our production site repos which are used in deployment scripts, while a post-receive hook pushes this to github as a read-only mirror. This seems to make a lot more sense than putting all our eggs in one basket with github (which is a big no no).
    • ^
    • v
    I don't think hosting your own public repository over HTTP in Git is absurdly complicated (by the way, you can host via SSH, or via git protocol using git-daemon). You should share bare repository, and "dumb" HTTP protocol requires extra info present, which is provided by git-update-server-info, and which is automated by the use of update hook.
    • ^
    • v
    Good post.

    This was always going to happen - there's been a lot of uptake of git because its "the latest thing" rather than because they've understood and evaluated its pro's and cons.

    And lets face it - we've all made that mistake at some point.

    On the upside while these dev's may be missing the point of the D in DVCS at least they're using a VCS, I'm frequently appalled by the number of so called experienced developers I speak to who don't get it at all.
blog comments powered by Disqus