[platinium]

On the plus side, this disastrous calamity by Github really made me try out Gitlab and in the process, I will now set-up a second remote on my repo's:

https://stackoverflow.com/questions/11690709/can-a-project-h...

  Quoted:
  "Try adding a remote called "github" instead:

   $ git remote add github    
   https://github.com/Company_Name/repository_name.git

   # push master to github
   $ git push github master

   # Push my-branch to github and set it to track github/my-branch
   $ git push -u github my-branch

   # Make some existing branch track github instead of origin
   $ git branch --set-upstream other-branch github/other-branch"

Actually, I don't know why I pay for Github private repo's.. I might as well set-up two origins, one at Gitlab and one at Bitbucket, for all my privates. Then keep Github as a public front-facing portal.

[robinhood]

Every company at some point has some kind of incidents. It just happens. GitHub is most of the time rock solid and doesn’t deserve to be judged based on one major incident like this. On the contrary they need our support. Bitbucket and GitLab both have had problems of the same magnitude.

[platinium]

But a multiple origin solution seems the most sensical. We have failover for everything infra and services.. it seems we now need failover for cloud-based code. It just seems logical, especially if all 3 of the big cloud providers have big incidents.

[shaklee3]

I think it's more about people not looking for alternatives while things are going smooth. Now they will, even though the grass my not be greener.

[simlevesque]

Why does GitHub need my support ?

[Shank]

> this disastrous calamity by Github really made me try out Gitlab and in the process

Every company faces problems like this. GitLab infamously lost their entire production database [0] -- and I think we can agree that's more serious. Knee-jerk reactions to incidents will leave you without any "trusted" services, because mistakes happen to everybody at some point. BitBucket has certainly had its own fair share of downtime.

[0]: https://about.gitlab.com/2017/02/10/postmortem-of-database-o...

[ikornaselur]

> GitLab infamously lost their entire production database

What?? The link you posted says

> Database data such as projects, issues, snippets, etc. created between January 31st 17:20 UTC and 23:30 UTC has been lost. Git repositories and Wikis were not removed as they are stored separately.

> It's hard to estimate how much data has been lost exactly, but we estimate we have lost at least 5000 projects, 5000 comments, and roughly 700 users. This only affected users of GitLab.com, self-hosted instances or GitHost instances were not affected.

How is that "their entire production database"? You make it sound so much worse than it was. While it was a horrible incident, they did not lose their whole production database.

[PuffinBlue]

Technically they did, for a brief period (24 hours??) at least, they just restored it from backup.

That was the final last ditch backup too where something like 5 out of 6 of the planned backups weren't actually working and nobody realised.

So you're right, they didn't lose it, but they came pretty damn close!

[codefined]

Picture of the Google Docs post on what they tried (which appears to no longer be available online) can be found:

https://femto.pw/6bsm.png

As a reference to the above poster.

[gumby]

> Actually, I don't know why I pay for Github private repo's.. I might as well set-up two origins, one at Gitlab and one at Bitbucket, for all my privates. Then keep Github as a public front-facing portal.

You do realize that every cloned tree can be a git "repo", regardless of the machine it's on, right? GH and GL surround the repo with some other things (bug reports etc) to rope you in but if you are cloning from one to the other you already aren't migrating that stuff as well, so it's not really clear what additional value that provides.

Is there something I'm not seeing?

[platinium]

Which brings into question... what is so special about the "front-end" features that Git provides? Why not use another third-party service that integrates into your Github/Gitlab/Bitbucket repo, storing the meta data of all the pull requests, code reviews, discussions, etc, inside a "meta repo" itself? I see this incident as an important note in taking steps to decouple important "meta" features from the cloud-host itself. It will be better to keep the cloud hosts as a bare bones skeleton that we can swap in/out at will (Github, Gitlab, etc), and then use another layer on top to provide all the nice fancy features.

[LaserToy]

Based on what I read on their engineering blog they will eventually have a similar outage.