Live data from Hacker News

GitHub Git Operations Are Down

githubstatus.com

261–270 of 271 posts

Re: GitHub Git Operations Are Down

#261
post #13

It's almost as if only Git is distributed, but people sold out to Github for convenience. Too bad Git lacks a distributed bug tracker and wiki system like Fossil. Guess Github has to fail a lot more for things to change.

If you have a local development setup, few hours of not being able to push should be a not problem most devs.

Except if you have a release planned but most don't at that time, statistically.

Problem is that people get comfortable with pushing to branch -> deploying in dev and testing from there.

Re: GitHub Git Operations Are Down

#262

Earlier quoted context omitted.

> You're just indulging in hyperbole for the sake of it. Nobody said git has an issue tracker in it. Yes they did. That's what this comment thread is about. https://news.ycombinator.com/item?id=42691624 (Unless you're splitting some really fine hairs about what "in it" means?)

They just mentioned the most common communication tool used with Git? You're the one splitting hairs here.

They mentioned them as a counterargument to "Too bad Git lacks a distributed bug tracker".

Which makes it a claim that those tools are git's distributed bug tracker.

A bug tracker and an issue tracker are basically the same term. So that's a claim that git has an issue tracker.

So when you come along and say "Nobody said git has an issue tracker in it." you are either wrong, or you're saying the words "in it" completely change the meaning of the sentence.

If it's the latter, that is a very unhelpful way to communicate, and is definitely splitting hairs. And honestly it's a strawman too because the comment you replied to wasn't using the words "in it". They were saying that you shouldn't say "git has" email. Which is a direct reference to the ancestor comment's claim. It was not hyperbole.

I'm not splitting hairs anywhere. I'm saying that the ancestor comment has the same meaning as "git has an issue tracker". That's not splitting. It's the opposite of splitting.

Re: GitHub Git Operations Are Down

#263
post #136

Earlier quoted context omitted.

I'd be curious by how much they downplay downtime. Wouldn't be too hard to put together an honest status page that pulls & pushes something new to main every 5 minutes, creates an issue, comments on it etc. Very basic high level checks.

PMs would never let an automated system make the company look bad, nor would they let engineers have time to build such a system.

I was thinking of a guerilla uptime monitor here, not one maintained by GitHub but independently.

Re: GitHub Git Operations Are Down

#264
post #166

Earlier quoted context omitted.

Hg names the branches and keeps the name. The other day I was looking at a sequence of commits trying to figure out where they came from and knowing the branch would have helped. mg always kept history though. Git has always encougaged squashes and rebase to keep a linear history so that information was lost.

We all want history information to be lost. (Unless you are running a version control system that timestamps every keystroke.) Reasonable people may disagree on what information should be kept.

While true I still find it strange that git still doesn't address this which hg has always used to say why it is better. There is something to it that git fans who have never had good brancing don't know what they are missing.

Re: GitHub Git Operations Are Down

#265

Earlier quoted context omitted.

Except you’re not considering the cost of when you can’t deliver something on time for a customer because infrastructure you don’t control is down. You don’t outsource things that prevent you from doing your core competency.

And for most companies, building and managing an SCM is absolutely not their core competency. Your point is valid, but not in the way you're trying to convey it.

> building and managing an SCM is absolutely not their core competency.

Building their software is - Github being down is currently preventing that for many companies.

Re: GitHub Git Operations Are Down

#266
post #223

Earlier quoted context omitted.

There is no reason to host 'decentralized' tools besides regulation. It's considerably cheaper to use GitHub (or other alternatives like GitLab) than hosting your own and hiring people to maintain and support the solution. Their issue tracking system is very convenient for small teams too.

> It's considerably cheaper to us This is not true. The cheapest option is to not have services that require servers to maintain. Git continues to work if GitHub is down. So do shell scripts when CI is down. So why can’t we have an issue system where the underlying data is text files in a git branch? I understand at scale you can pay people to optimize a process for the larger team, but there is a ton of unnecessary…

If you're collaborating with a small group of people (or you're not running a huge amount of CI/CD) then you can make almost anything work. Once you get big it's another story entirely.

Re: GitHub Git Operations Are Down

#267

Earlier quoted context omitted.

Exactly, hire a team of 3 and pay 500K in compensation, or spend 100K on a system that works and you get a support person to call in the event of an issue. The math is so simple.

Except you’re not considering the cost of when you can’t deliver something on time for a customer because infrastructure you don’t control is down. You don’t outsource things that prevent you from doing your core competency.

The costs would be trivial for the vast majority of Software Engineering companies. Talking about corner cases is useless as they often need a custom specialized solution anyways and wouldn't be using GitHub in the first place.

Re: GitHub Git Operations Are Down

#268

Earlier quoted context omitted.

And for most companies, building and managing an SCM is absolutely not their core competency. Your point is valid, but not in the way you're trying to convey it.

> building and managing an SCM is absolutely not their core competency. Building their software is - Github being down is currently preventing that for many companies.

Nope, sorry. Github offers cloud and on premise offerings. If you choose cloud and your company can't handle a 45 minute service outage, that's just a bad purchasing decision. You do realize they make most of their revenue from on premise enterprise customers and that none of those customers were impacted? The solution was there the entire time but they can't force people to use it.

Re: GitHub Git Operations Are Down

#269
post #74

Earlier quoted context omitted.

Agreed, I wonder what their downtime percentage is. If guess it's down on the order of one hour per month, so 1/1000. Update: They promise >99.9% on a quarterly basis for enterprise customers - https://github.com/github/docs/blob/main/content%2Fsite-poli...

99.9% uptime corresponds to about 2 hours downtime per quarter, if my maths is correct. If that is indeed the guarantee, based on the experience at my company, GitHub has failed its promise recently (or is getting damn close). I recall 2 decent outages in the past few weeks alone. It's making me begin to doubt if GitHub's reliability is appropriate for an enterprise service.

I'm not sure whether the uptime guarantee is 99.9% independently or jointly for each service, i.e. if service A is down for 0.06% and service B another 0.06% but not at the same time, will this count as overall uptime >99.9% or Rereading the SLA, it looks like Github can have each service feature like issue, pull requests, git operations be down 0.1% and still not reimburse. In your head you might not account separately for each feature, but Github does.

Re: GitHub Git Operations Are Down

#270

Earlier quoted context omitted.

> building and managing an SCM is absolutely not their core competency. Building their software is - Github being down is currently preventing that for many companies.

Nope, sorry. Github offers cloud and on premise offerings. If you choose cloud and your company can't handle a 45 minute service outage, that's just a bad purchasing decision. You do realize they make most of their revenue from on premise enterprise customers and that none of those customers were impacted? The solution was there the entire time but they can't force people to use it.

It's surreal to imagine most companies not being able to handle a 45-min service outage of a VCS to begin with. Sounds to me like a GitHub mandated break for all SE 's.
Post reply on HN