Whenever GitHub runs into problems like this, it reminds me of when a team's CVS or Subversion servers used to go down. It could be a pretty disruptive occurrence, if it wasn't resolved quickly. While git can theoretically handle this better, in practice the use of GitHub, for instance, renders git just as susceptible.
If Github were to explode forever tomorrow, active projects would just take their locally cloned repositories, and put them online somewhere else and carry on committing (albeit sans github's awesome social tools). That's the real power git offers us.
It's just a fact of reality that most projects centrally organize through a few bottlenecks. It's easier for people to remember where to go, if there's only one place to go to. But if you're really concerned about it, i suppose you could build a tool to automatically sync a github repo w/ another 3rd party host if you wanted (or visaversa).
So even if bugs.kde.org were to go down, we'd still be able to fix code at git.kde.org, and use the lists.kde.org mailing list archives to lookup bug details as a backup. We'd probably use a mailing list system that doesn't suck like kde.markmail.org or GMANE for that last part, but that's just shaving the yak...
Is there a git tool to share your remotes in a repository?
One could use a distributed issue tracker like "Bugs Everywhere"[1] or git-issues[2]. Are there ways to "sync" them with Github's issues?
[1]: http://bugseverywhere.org/ [2]: https://github.com/jwiegley/git-issues
It's crazy how GitHub's entire product is so easily marginalized by comments like this. I don't know if you meant to do it, but I think it is a serious problem with hacker culture. It's the kind of thinking that tricks startups into "knowing" they can do a better job than established competitors in spaces they know close to nothing about, because they "know" they can execute better. I speak from personal experience here.
I can guarantee that no amount of "adding some scripts/utilities" will get near what GitHub's service offers.
Just because you tried and failed, doesn't mean every try will fail.
I don't think they were saying that a few scripts and utilities would get you what github offers. I think they were saying with some scripts you could automatically fall over to another mirror when github goes down, then switch back when it's up (updating the repo on github when it's available again).
The word "add" here is important, as it's talking about having github and something else. So you get github (with all their social stuff...) AND what the scripts add, which is more reliability.
Creating and hosting a repo locally (or offsite) is trivially easy, and though it might not be as friendly or natural as it would be with git on a daily basis, it's not impossible either.
It isn't odd. Almost nobody understands distributed version control, and fewer actually need it.
A big part of the reason that GitHub is popular is that git is way too complicated for most people to use. They don't understand the CLI or the concepts, and need a shiny web UI to abstract the (admittedly terrible) interface.
Most people need branching, merging and committing to a canonical repository. Even the groups that could theoretically benefit from distributed repos (larger, far-flung organizations), tend to be hamstrung by the complexity that they introduce, and therefore in practice tend set up a small number of canonical repositories...just like every other version control system, but more complicated and confusing.
git remote add my_other_server_that_is_not_github git://my.oth.er/server/that/is/not/github.gitThere's no reason you can't do the same thing with a small box in the office and get the best of both worlds.
Anyone happen to know a way around this specifically? Trying to install some stuff and brew just bails after getting 5xx from github.com.
Periodically you can merge upstream into your clone to get updated recipes. (e.g., the aforementioned cronjob can mirror master from github to remotes/upstream/master in your repo, then separately you merge that into your master).
Your servers are now immune to github outages[1] and you can review recipe updates before your servers update to those recipes.
[1] unless of course the recipes you're using are hosted on github. But you could recursively mirror those sources too and modify the recipes as needed.
edit: I'm on a mobile device but I can provide further details the next time I'm in front of a keyboard in case this wasn't clear.
Yeah, the problem I was having at the time was that Homebrew was trying to fetch a tarball hosted on Github. I was just whinging though, that was the only time I've ever hit that particular snag.
The system you propose would be great, but more work than switching to running headless Linux VMs on OSX for most dev work ;) This is something I have been drifting toward for a while now, using Vagrant.