I do sense a bit of fail reading some of these Twitter messages. Pull from your co-developers, or clone on a shared box somewhere and use it, or use the hypertrophic patch management. Some guy is editing code in prod? Why, you can't change one line in your deploy process (config/deploy.rb in Rails) to point it at your local repo?
GitHub is a success because it's incredibly convenient, but it doesn't add functionality to git.
Since they make a repo mirror every time they pull, why don't they have a backup? Do their developers never communicate with each other? (Why are they using github as their build repo?!)
With mercurial, you can just run "hg serve" or "hg -p [port] serve", FWIW. (That's for a read-only repo, though. There's a bit more setup involved before people can push to an http repo.)
With monotone ("mtn serve", done. Auth is taken care of at the repository level) and darcs it looks even easier.
For the record, the author of those flowcharts is completely missing the point. You can just as easily call `git update-server-info` and copy the .git from your repo into a web-accessible directory, and just be done with it, the same as Darcs.
The reason people do it other ways (either via git-daemon, gitosis or ssh) is because Git uses a special transport protocol that's far more efficient than a dumb HTTP session. It's not that Git won't work over a dumb HTTP session, it'll just be a lot faster using it's own server/protocol.
All of the alternative tools - bzr, hg, darcs - have highly optimized protocols as well. This may be a documentation issue - I've never seen documentation for using a dumb server with git. Also, can clients submit changesets back via simple FTP? Darcs can, IIRC.
No FTP support, but that's insecure; what's wrong with using SSH? And there is documentation on the Git website (and in the source tarballs) on how to set up an HTTP-hosted repo, and even how to set up for a WEBDAV-enabled push repo, although I've never attempted the latter.
2 things. 1) many people who use GitHub do not understand distributed VC, and treat it as a central repo. GitHub is trying to do education here, and has published the disaster guide sant0sk linked to.
2) GitHub is more than just a git repo. It's a social network. People use it to find code, explore code, paste code snippets...so when GH is down, a lot of interaction can't take place.
It's not tough to heap together a few complaints out of a day's worth of tweets.
The fact is that many GitHub users, myself included, noticed GitHub was down and went on our merry way coding and working and doing whatever.
I didn't "heap together a few complaints out of a day's worth of tweets". That's a single contiguous chunk (spanning less than an hour, as you can see) of the results for "GitHub" on search.twitter.com yesterday.
Yes, I was annoyed that GitHub was down, and twitted about it. And then a minute later I was pulling fro a co-worker across the room. (Life goes on; twitter is fun for near-frictionless griping.)
It's not that a GItHub failure makes everything stop, it's the convenience factor, and that they are offering this as a for-pay business service, that makes it irksome.
Nah, it's probably just a good sign that some people don't really understand what makes git different from svn, they just keep hearing it's "the best", so they use it.
GitHub is a success because it's incredibly convenient, but it doesn't add functionality to git.