81–90 of 147 posts
This is why I love git (and distributed version control systems in general). For the most part a short downtime isn't the end of the world. When it comes back up I'll push my changes and that'll be that.
Unless the Mayans were off by one
I did a bunch of work on GitHub today just before it went down. Talk about getting lucky. I'm sure we will all learn a bunch from the post-mortem. These high-profile and very openly discussed failures are always good for learning all kinds of things. No issues at all on how GitHub is handling it so far. Eager to learn what happened. Hitting refresh on the status page every so often. Better than watching underwater ba…
Earlier quoted context omitted.
Ah but i meant a global service for public repos, instead of each owner setting up manually
A remote can have multiple url entries. 'git push origin master' in my case pushes to Bitbucket, then GitHub. Must be manually added through 'git config -e' though. The order is important as it pulls from the first remote URL, while the push is to all.
What i mean was for a web service that would monitor changes on public repos (commits, tags, branches) and would sync them automatically (mapping accounts, pruning branches, etc).
Earlier quoted context omitted.
Your company runs its source revisions through Github without a backup solution? Do you really put all your eggs in a basket you have no control over? I know that in theory a cloud solution should have a higher uptime than an amateuristic set up private server, but cloud solutions have a certain complexity and coherence that make them very vulnerable to these kinds of 'full failures' where nothing is in your control.…
Add up your downtime over a three year period by relying on Git (or gmail, or AWS) versus the cost of trying to engineer some local-backup system, and the downtime associated with that going awry. Outages happens - as long as we're talking hours a year, pretty much everyone but life-safety systems, critical infrastructure, and payment/high-traffic commerce sites are probably better off just letting third-party cloud…
Earlier quoted context omitted.
Exactly. I'm sitting here thinking "poor GitHub engineers" rather than "oh crap, how am I going to work?" (Though I do wish GitHub Issues weren't as centralized...)
One of the neat things about repos in Fossil (the DVCS by drh of SQLite fame) is that they have a built-in wiki and issue tracker whose contents are version controlled along with everything else in a project's repo. The Fossil executable also has a built-in web server that presents a web interface for working with the repo, including the issue tracker and wiki. In short, if you have a project's Fossil repo, you can w…
Earlier quoted context omitted.
Exactly. I'm sitting here thinking "poor GitHub engineers" rather than "oh crap, how am I going to work?" (Though I do wish GitHub Issues weren't as centralized...)
One of the neat things about repos in Fossil (the DVCS by drh of SQLite fame) is that they have a built-in wiki and issue tracker whose contents are version controlled along with everything else in a project's repo. The Fossil executable also has a built-in web server that presents a web interface for working with the repo, including the issue tracker and wiki. In short, if you have a project's Fossil repo, you can w…
Github issues aren't however.
That's a really nice status dashboard, tracking and publicly displaying your 98th% is really cool. On the other hand stuff like this: "13:17 UTC We are seeing unicorns ..." Comes off as un-professional at exactly the wrong moment.
Can't disagree more. Gives me the impression there are actually real people trying to fix things, not just blank-faced robo admins following company policy HOWTO-Fix guides. That github isn't a blank sheet devoid of life and emotion and all 'professional' is the reason I'm willing to shrug off downtime like this. If anything, I really feel for whoever posted: We do not expect this to have visible impact to customers,…
Just shows people aren't perfect. Haven't we all been there?
(I do agree though that it does feel like a slap in the face to say: "Hey there shouldn't be any problems! Never mind, we were wrong...")
This is why I love git (and distributed version control systems in general). For the most part a short downtime isn't the end of the world. When it comes back up I'll push my changes and that'll be that.
I had a clone of my personal fork of my department's github repository at home. I read this and thought "that's interesting, I wonder if I could still work on it from home if I want to." I saw with "git config -l" that I had my github repository and my university's github repository, but not my university's mirror of the repository. I did a "git add remote", logged in to my university's VPN, "git fetch", and was up and running with my latest changes from Friday.
If that didn't make any sense, well, the gist of it is that the outage wouldn't affect development work in the slightest, thanks to the fact that every repository is a) content addressable, so you have consistency between servers and b) self-contained, so you have a complete copy everywhere. Hit me up for more info if you're curious; I recently upgraded us from CVS to Git for this redundancy advantage, among others.
Earlier quoted context omitted.
Yup. I wanted to do some coding before heading off, but I guess that's off the table now.
What? That's the complete opposite of what OP was saying. You don't need github to be online to work with your code or even your repositories so long as you haven't gone and thrown all your digital eggs in the same basket (i.e. as long as you have other remotes or at least local copies of your repositories).
Most of developers in my countries 're using SVN. I don't use SVN at all, and i'm failing to convince my partner that Git is better than SVN, just because i don't believe in hardware stability.