Virtuous Code: You keep using that word “distributed”…
Dan_Mayer
· 1 year ago
Nice post, we are planning to move to git soon. Right now when we deploy all the code is sucked out of a public repro, I assume that was a problem most users were experiencing. It would suck to have to go to all our machines and tell them hit up an alternative repo. Any thoughts on how to be avoid that using the distributed nature of git?
Chris
· 1 year ago
I completely agree. I'm trying to find out why people think they need GitHub when it's down for anything other than fresh public clones.
We've advertised our Disaster Recovery Guide (http://github.com/blog/175-github-disaster-guide) a few times, but I think not enough people know about it. You can still share and deploy GitHub-based repos when the site is down - that's one of the joys of distributed version control.
Mike H
· 1 year ago
I think that the important point here is that GitHub was down, but everyone reasonably expected that it would be back up within a short period. Given that, the effort involved in modding your workflow to not use GitHub wasn't worth the benefit over waiting an hour or two.
Collin
· 1 year ago
I suggest GitTorrent
(er I suggest that somebody design and implement it)
mitchellh
· 1 year ago
I completely agree. I think its funny how people focus everything around github. For example the one tweet that says "now i'm manually changing code on a live production site" should never be using his github git repo as a dependency for deploying to his production site. If anything he should set up (even if its difficult, 5 minutes save you a ton of pain) a publically accessible git repo either on his computer or some other server which his deployment can depend on.
And even if that goes down, since everyone who has the repo has the ENTIRE repo, you can just point your deployment scripts to the new repo and hurrah it works.
My company uses an internal git server for hosting all our production site repos which are used in deployment scripts, while a post-receive hook pushes this to github as a read-only mirror. This seems to make a lot more sense than putting all our eggs in one basket with github (which is a big no no).
Jakub Narebski
· 1 year ago
I don't think hosting your own public repository over HTTP in Git is absurdly complicated (by the way, you can host via SSH, or via git protocol using git-daemon). You should share bare repository, and "dumb" HTTP protocol requires extra info present, which is provided by git-update-server-info, and which is automated by the use of update hook.
James
· 1 year ago
Good post.
This was always going to happen - there's been a lot of uptake of git because its "the latest thing" rather than because they've understood and evaluated its pro's and cons.
And lets face it - we've all made that mistake at some point.
On the upside while these dev's may be missing the point of the D in DVCS at least they're using a VCS, I'm frequently appalled by the number of so called experienced developers I speak to who don't get it at all.
All Comments
We've advertised our Disaster Recovery Guide (http://github.com/blog/175-github-disaster-guide) a few times, but I think not enough people know about it. You can still share and deploy GitHub-based repos when the site is down - that's one of the joys of distributed version control.
(er I suggest that somebody design and implement it)
And even if that goes down, since everyone who has the repo has the ENTIRE repo, you can just point your deployment scripts to the new repo and hurrah it works.
My company uses an internal git server for hosting all our production site repos which are used in deployment scripts, while a post-receive hook pushes this to github as a read-only mirror. This seems to make a lot more sense than putting all our eggs in one basket with github (which is a big no no).
This was always going to happen - there's been a lot of uptake of git because its "the latest thing" rather than because they've understood and evaluated its pro's and cons.
And lets face it - we've all made that mistake at some point.
On the upside while these dev's may be missing the point of the D in DVCS at least they're using a VCS, I'm frequently appalled by the number of so called experienced developers I speak to who don't get it at all.