6 ms·
I find it somewhat odd that, given git's emphasis on distributed version control, we see so many git users have centralized themselves quite heavily on GitHub.
by PommeDeTerre 13y ago
I find it somewhat odd that, given git's emphasis on distributed version control, we see so many git users have centralized themselves quite heavily on GitHub.
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.
- 0x006A 13y agoThats not true, with CVS/SVN you can not commit, log or do anything while the server is down. With git you can still commit to your local tree, push it to another server or send patches. While it might slow down workflows using github.com for push/pull its not that complicated to temporarily push/pull via another server.
- k3n 13y agoPlaying devil's advocate here... but if you were so inclined you could accomplish the same with SVN. 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.
- knowtheory 13y agoHow is it at all odd? Github offers a convenient platform for using git. People use it. 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).
- appplemac 13y agoYes, but Github is not just about Git hosting, it's about all those awesome social tools. If you use Issues as the main bug tracker, for example, you've got a problem.
- justizin 13y agoPlease point me at your distributed issue tracker project. I'd love to contribute!
- ryanpetrich 13y agoFossil includes distributed issue tracking: http://www.fossil-scm.org http://www.fossil-scm.org
- mpyne 13y agoAt KDE we use Bugzilla with automatic status emails to various mailing lists and projects. 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...
- kanzure 13y agohttp://bugseverywhere.org/ http://bugseverywhere.org/ does distributed bug tracking.
- TkTech 13y agoYou can also add multiple urls to your remotes. When you push, it'll go to all of them. I do this at home with a tiny server on a mini-atx box and github. Set it and forget it. There's no reason you can't do the same thing with a small box in the office and get the best of both worlds.
- bluedino 13y agoIs it that simple? Just pony up another $9.95 for a VPS and you've got git access to your repos whenever GitHub is down.
- spacemanaki 13y agoEven worse is other tools that rely on Github, like Homebrew (Mac OS X package manager) which breaks in various silly ways when Github is down. Anyone happen to know a way around this specifically? Trying to install some stuff and brew just bails after getting 5xx from github.com.
- glurgh 13y agoTry ports, perhaps? http://www.macports.org/ http://www.macports.org/
- js2 13y agoClone the homebrew repo. Use a cronjob or Jenkins or some such to periodically fetch updates to a server under your control. Modify homebrew and its setup script to use your repo (it's been a while since I did this but the Github URL for the homebrew repo used to be hard coded in one of homebrew's ruby scripts). Whenever setting up a new machine, use the modified setup script. 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.
- spacemanaki 13y ago> unless of course the recipes you're using are hosted on github 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.
- elithrar 13y ago
- coherentpony 13y agoWhat? git remote add my_other_server_that_is_not_github git://my.oth.er/server/that/is/not/github.git
- saraid216 13y agoThe problem is mostly that people fail to actually do this.
- Anderkent 13y agoUntil github goes down, and then they run `git remote add friend ssh://coworkers-workstation//path/to/repo` and push code to each other until github comes back up.
- coherentpony 13y agoWell, pushing to someone else's local copy is a little harsh, since that copy probably won't be bare. Also git will slap your wrists if you try to do that. Instead, the coworker should pull from you. This is why GitHub's calls them pull requests.
- icebraining 13y agoOr you can push to a different remote branch, and then they can merge it with their master.
- timr 13y ago"I find it somewhat odd that, given git's emphasis on distributed version control, we see so many git users have centralized themselves quite heavily on GitHub." 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.
- brown9-2 13y agoDo you have any info or anecdotes about work actually being disrupted because GitHub was unavailable?