DISQUS

DISQUS Hello! Virtuous Code is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

Jump to original thread »
Author

You keep using that word “distributed”…

Started by avdi · 8 months ago

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 ... Continue reading »

7 comments

  • 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?
  • 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.
  • 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.
  • I suggest GitTorrent

    (er I suggest that somebody design and implement it)
  • 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).
  • 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.
  • 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.

Add New Comment

Returning? Login