Hacker News Reader

Comment by rdtsc | Hacker News Reader

Whenever Github goes down I always wish someone would invent a decentralized version control system.

Remember at work when Github goes down everyone is just sitting there twiddling their thumbs for hours. As in "yeah my commit is ready just waiting to push it" or "waiting for the issue to be close, then we can test".

It is ironic a bit isn't it. One of Git's major selling points was -- we are tired of one centralized version system, you shouldn't need a single point of failure or be tied to the network in order to develop. And then years later we have one giant global single point of failure across the world. There is some irony there.

(Yeah, yeah, I know I can commit locally. But at some point you'll need to update issues, and publish your changes. This is more a of a generalized point. It would be the same if bitbucket went down and so on. We never it seems have gotten to the mythical peer 2 peer internet of things -- it just doesn't work it seems).

View on HN

> But at some point you'll need to update issues, and publish your changes.

The second part is solved. You just need a second git server. Maybe Bitbucket, or maybe your own. We just never do it though, for reasons I don't know either. I don't do it, even if I know how. There are multiple tools to push to different servers automatically, but we still go the comfortable route. Maybe it's the psychological thing that "if Github goes down it won't be for long, is it really going to affect me?".

Because of that I don't agree the tools are the problem though. Or even that they are part of some irony. Git delivers on its promise. People just don't use it like that.

The issues part or the dependency with Github to test/deploy software is more of a vendor lock in situation. A lot of people depend on it being up to work, but that's the convenience charge since Github isn't open source. Not much different from people depending on Heroku to be up for their application to function.

On that note, question. Is there an easy way to create mirror servers?

For instance, have a Github repo but also a personal Git server and Bitbucket. Whenever you do `git push`, it'd update all three. And all three would be in sync.

There are a few ways.

You can create a single remote called "all" that has all your servers URLs. Then you can just push to that one, like "git push all", and all your servers will update. Pretty much the simplest, you just need to edit the .git/config.

You can set up a mirror too ("git remote add foobar --mirror=push ..."), but I've never done that.

Or make a hook so that whenever you push to a remote it also pushes to another.

There's also mr[1], which I've heard of but not used.

There are ways aplenty, we just neglect to use them.

[1]: http://myrepos.branchable.com/

It is very easy to setup a shared git server.

http://git-scm.com/book/ch4-6.html

If you can mount it (w/ write permissions), you can push to it. Most companies already have a networked storage place.

We don't use github, but when our server is offline, we just spin up a VM from backup, push the latest commit to it and start using it as the new centralized server. I think what you lack is a decent policy, not technology.

Having a VM and two separate places for the canonical repo is bad policy. If you have this centralized server why do you also have Github?

OP doesn't use GitHub if I read his/her comment correctly.

However... having multiple remotes is a very easy way to get multiple distributed backups of your code. (You should do a "git fsck" on all your mirrors at least semi-regularly. The reason has to do with how push and --mirror work.)

Git is distributed, but obviously you're going to have a canonical repository somewhere (git.kernel.org, for instance). Decentralization doesn't mean getting rid of a canonical place where approved patches end up, and you really aren't going to see canonical repositories disappear, we have them for a good reason.

However, there is something to be said about mirroring canonical repositories for accessibility.

Do you even understand git? Literally push the whole repo wherever you want. git remote add blah. It doesn't matter where it's hosted. Many popular projects push their code to multiple services -- it's not harder than pushing to one.

If github goes down and your devs are twiddling their thumbs because they can't push, you have larger problems.

Wait are you trying to use the "do you even lift, bro" meme but referencing git? That's funny.

Yeah, I have been using it for about 5 years. I know how git works

> Many popular projects push their code to multiple services

What does that mean "multiple services"? Multiple machines?

> But at some point you'll need to update issues

You can reference (and thus comment on) and close issues from your commit messages.

> and publish your changes.

That does not require sitting on your ass and doing nothing though.

One of the big selling point of github is how little downtime they have.

But when they do, hundreds of thousands of developers sit there waiting for it to come up.

Who are these people, who are incapable of writing product code or tests, or catching up on documentation writing, or stepping back to think about design, or just reading some of the code to learn it better?

These are the people who made the mistake of signing up to a service with a central point of failure in the whole world. When that goes they have to find out other things to do.

But of course it is their fault for not having anything else to do and so someone on HN tells them that, "Well trust me this is totally fine, you guys and gals just need to do something else at the moment. Don't think of it as a bug, it is a feature built it to help you multitask..."

Reply on news.ycombinator.com