Aside from the fact this argument falls apart when you use submodules or third party repos, a lot of us use GitHub for the services they offer beyond just git.

After you have init'ed and updated your submodules, the argument holds fine.

Sure. When GitHub is online, the argument holds fine as well. I fail to see what difference that makes. Clearly the situation being described is when the submodules aren't init'd and GitHub is down (e.g., bringing up a new server and deploying with Capistrano).

If only there were some way to mirror submodules or other third party repos to your own servers without needing github.

Oh wait, this isn't svn.

I think he's also referring to website hosting, issues, wiki, etc.

Sure, there is, but then why do I pay for GitHub? And I was mostly alluding to pull requests, issues, pages, etc. All the non-git stuff that I rely on being available as well.

The outage probably isn't going to last forever. And it's very unlikely you'd need to refresh third party repos in the time github is down.

Now if you're juuuust looking for some library or its README/documentation (I usually use Github for that) ... well I'm sure going for a walk for a few hours won't hurt you :)

Your statement was "If only there was some way of using git locally without needing github". Stick to it and save the theatrics. Git is a software package that you can download and use, yes Virginia, "locally". As to the availability of a remote host serving a precious resource not being available, well Virginia, those are just the facts of networking life.

It's actually quite likely. If you have a git repo listed in a Gemfile, for example, and you need to bring up a new server or deploy, you're going to have problems. Sure, the outage isn't going to last forever. But the standard, snarky reply about git working fine locally is really tiresome.

Instead of a snarky reply, perhaps someone will think of a good solution.

The simplest possible thing: instead of supporting a single git URL, allow specifying several. That way, if anything goes down the system can fallback to the next git server.

Another nice benefit of doing this could be automatic load balancing.

In my experience most Rails deployments and CI setups depend on Github being up. While it's possible to bundle and copy code on deploy rather than checkout from the server, most projects don't.

So of course you can continue developing locally, but if Github is down, it means the release/ci process is likely broken. I'm not saying this is Github's responsibility, but it's a reality for many people. It's another sales point for Github Enterprise.

My company uses github enterprise, which is a VM that's very easy to make highly available.

Link: https://enterprise.github.com/

With licenses not available for less than 20 seats, it's not really feasible for teams of 10 or less.

I would think that $5k/year would be a small price to pay for backing up your code, especially if your business model relies on coding every single day.

There are also major security reasons to do this -- not relying on github to secure their website/application, which they have already failed to do in the past.

Assembla has a installable repository manager for unlimited SVN and Git projects on your server and it is free for up to 10 users. http://portfolio.assembla.com/repository_manager.html

Ever tried using gitX? I really like it.