I would love to see a chart of traffic to other sites when GitHub goes down. My bet is that HackerNews and Twitter both get significant spikes from all those bored developers.
Bored? Git's a distributed version control system, so no excuses. Get back to work!
But in all seriousness I kind of wish GitHub provided a way to mirror things like issues and PRs so you never have to be fully reliant on one service. Not being able to read these really does make it impossible to get work done offline.
My inner cynic says that that's probably the reason why they don't provide this service.
Github is not a open source company, it is not really even a supporter of free software IMO they are a danger to free software for this very reason. They are following the old school Microsoft model of Embrace and Extend... I am waiting to see if they can extinguish,
I'm sure they employ direct maintainers/contributors to other open source projects as well.
Which is a Microsoft product, and Microsoft is the inventor of EEE. Ergo, GitHub is complicit in an EEE attempt. Q.E.D. Case closed.
/s
They are actively working against open source tooling for software development by developing features only for their closed platform.
Gitlab is a much better example of a company that fully embraces open source.
GitLab Enterprise Edition does not have an open source license. Since GitLab.com runs GitLab EE, their two (presumably) primary sources of revenue (EE licenses and GitLab.com paid accounts) come from non-open source software.
But: it's still fair to call GitLab as a company way more Open Source than GitHub. All of their development happens out in the open, the vast majority of their codebase is Open Source, and the source code for GitLab EE is even made available.
This is a spectrum, not black and white.
To me in order to be a Open Source company your primary product must itself be Open Source.
RedHat as an example... RHEL is open source
GitLab.. GitLab is open source
These are open source companies
Hiring a few devs for work on some side projects that are open source does not make one an Open Source Company
If they open GitHub Core then they can claim to be a open source company
Also as mentioned elsewhere in this thread, Github has published plenty of open source software. Electron, Atom, resque, and updates to git itself.
As I clearly stated, GitHub can not be a Open Source company simply because they hired some devs to work on Open Source
Do you consider Microsoft to be a Open Source Company?
A more likely strategy/motivation is that the product is you. AKA: farming the users.
Create a desirable pasture, and the animals farm themselves.
Get a bunch of Open Source Developers to do your marketing at their "real jobs" so they can sell the Enterprise Version.
Since GitHub is a private company it is Unknown (at least I can not find the info) if they are profitable or not, or what their revenue numbers even are so it is unclear if that is a successful plan or not.
GitHub could very well run into the same problems as SoundCloud.
Sorry, but this is unfair :) I remember the early days of Gitlab, before they added all the insanely cool features they have now, when they were just a Github opensource copycat. My thought at the time was : "wow, github is super cool to let them go. At least the almost exact design copy could be a legal problem". Clearly, we would have heard about Github vs Gitlab back then, if Github wanted to lock people in.
You do not hear about many VC funded startups initiating lawsuits for a reason. That is the realm of established companies.
GitHub clearly contributes a fair bit to open source - not only their own projects, but the free hosting for open source projects. You have no basis for this accusation, and frankly we are all stupider for having read it.
I love it, and it's perfect for when you want to say something witty like FUD or D&D, but can't justify it. Now with CIM, I can!
1 Claim was that Github is not a open source company, and they are not. Their core business is not open source, yes they have some side projects that are, but so does MS, I do not believe anyone is going to say MS is a "open source company"
the second claim I made is they are a threat to free software, I used free software here for a reason, free software and open source are different.
GitHub may support some Open Source things, they do NOT support free software.
Tom Preston-Werners infamous post on open sourcing only some things (http://tom.preston-werner.com/2011/11/22/open-source-everyth...) Is a key piece of evidence to prove this.
Git hubs general actions over the years show they do not support free software at all, and have limited support for Open Source software.
They are classic Free Software leaches, using and abusing free software not for the ethical reasons around free software but to advance their profit center
See I am support free software for ethical reasons, not monetary reasons.
That is with out even getting into the MASSIVE issue that is having all of these open source projects on a SINGLE platform. Unless you think github is "too big to fail" which I can assure you it is not
Also as others pointed out, just because the GitHub app is down doesn't always mean the GitHub git server itself is down.
How about storing issues and PRs in the actual git repository? They should index them for the UI, sure, but the source of truth should be a branch of the git repo just like it is with gh-pages. It should be possible to file a new issue by committing a markdown file to the correct branch and pushing it to Github. Their hub command line tool and their own client could facilitate adding all the correct metadata. This would allow people to work while Github.com is offline and synchronize everything once the service outage is over.
If you have access to a distributed database that is already the best available for manual conflict resolution, why wouldn't you want to use it to store this kind of data? A Github outage is like a partition when you think about it from a distributed db perspective, so treat it like an individual node died and still allow reads/writes to the rest of the cluster that can be merged back once the node comes back online.
Access to the git repository is regulated; issues and PRs aren’t. Anybody can fill an issue/PR on your repo, but only you (and your team) can modify the repo. You’d need to also store all the comments on all issues and PRs, even closed/rejected ones. In some repositories, that’d be huge.
And the amount of actual data needed to store issues is peanuts anyway.
It’s not. Take something like github.com/Homebrew/homebrew-core. There are 15k closed PRs there. There have been 20 new ones today. It’s not rare to have 10-20 comments per PRs; some of them even go over 200. Add CI status, actual PR contents (git patches), comments reactions, edits, labels, milestones, assignees, reviews, projects.
IMHO having a tool to fetch issues locally is a good idea; storing them in the repo is not.
So then we can slurp all of our GitHub & Gerrit history into RAM (takes about 5 seconds and 500 MB) via https://godoc.org/golang.org/x/build/maintner/godata#Get and walk it in-memory and do stuff with in. (runs our realtime bots, alternate web UIs on planes, alternate search, stats, etc.)
Nice work! But as is custom on HN, I'll bikeshed on the name instead of delving into the contents of the tool. Why shorten the word by just 2 letters? Is there something special about the tooling that makes 8-letter projects more desirable than 10-letter projects, or is it linked to the removal of Artificial Intelligence from the process? I'd personally mis-type that name all the time.
I commit to re-use this as often as possible!
http://www.urbandictionary.com/define.php?term=Excgarated
An inspiring new word invented by a redditor on March 23, 2014. The redditor was actually trying to spell exaggerated. This word was misspelled so horribly that when it was googled the only thing that came up was a link to the comment itself.
Could you expand on this? Sounds interesting. You mean like an offline UI powered by the in-memory mutation list?
Another model to look at is Trac, which had pretty extensive integration with SVN and integrated (ie, cross-linked) issue tracking and wiki, and stored all the data and change history in a svn repository.
Developer or Fossil and SQLite here: I agree. In my experience, you'd have better luck convincing the team to switch from vi to emacs. For all its many and well-documented faults, the Git/GitHub paradigm is what people want to use because it is what they are familiar with.
All the same, I intend to keep right on using Fossil, thank you very much!
So here is the idea I've been thinking of lately: What if Fossil were ported or enhanced to use Git's low-level file-formats so that unmodified git clients could seamlessly push and pull against the (enhanced) Fossil server. Call the new system "Fit" (Fossil+Git). Using Fit, you could stand up a GitHub replacement for an individual project in 5 minutes using nothing more than a 2-line CGI script. Git fan-boys could continue to use their preferred interface, while others who prefer a more rational and user-friendly design could use the Fossil-like "fit" command. Everybody could share code, and everybody would have a nice web-based interface with which to collaborate with tickets and wiki and all the other cool (and to my mind essential) stuff that Fossil provides. And nobody who already knows git would be forced to learn a new command-line interface.
I'd be all over writing the code for "Fit", except that I'm already over-extended. Anybody who thinks this is a good idea and would like to pitch in and collaborate, please contact me privately. Thanks.
First, a backend that works exactly like git is very different from one that works almost like git. You'll be blamed for other people's problems.
Second, you'll have to have a way to deal with commit history the way git does (arbitrarily, and able to be rewritten at any time)
Otherwise the first push -f or rebase breaks the whole thing.
Reading from and writing to a git backend (that is, making fit a client too) might be the safer option. Sort of like git-p4 in reverse.
GitLab I know models their Wiki as a git repo. I think issues and PRs should be their own repo as well.... a branch for each issue or pr? Could tie it all up using submodules (or not, whatever)... just please someone take the jump first and do this.
You might want to modify your scenarios.
There are active simulations going on: http://www.sciencerecorder.com/article.php?n=scientists-cond...
There are preparedness drills: http://www.independent.co.uk/news/world/americas/us-politics...
There's plenty of policy analysis: https://www.cato.org/publications/policy-analysis/social-eco...
Older .mil reports: http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA080907
There are entire books taking apart what happens in specific fields: https://www.ncbi.nlm.nih.gov/books/NBK219154/
Or you could just read disaster porn^W^W post-apocalyptic sci fi.
So, a lot depends on what kinds of info you want to find. But overall, I'd say it's not worth reading, because life's not going to be much fun. Even if you're prepared.
I see no reason to have a RDBMS for issues, merge requests, pull requests, etc. All of these could be modeled in multiple ways using a Git database. Issues are files in a repo called issue1.md, issue2.md ... or issues are branches on a repo ... or something else.
With git, every commit has an sha checksum of the commit contents & metadata. And each commit's metadata points to the previous commit.
So, if a maintainer wanted to fix a typo or do any other kind of correction/update to an old issue you'd need to rewrite every commit on disk since that one with the updated chain of checksums. eg from the fixed comment, to the head of the special issue/pr branch.
That alone would probably make syncing with the repo's a real pain for anyone working on medium to larger sized projects. ;)
It doesn't mirror issues and PRs but it can do a one time import of them https://docs.gitlab.com/ee/workflow/importing/import_project...
[0] http://fossil-scm.org/index.html/doc/trunk/www/index.wiki
From http://monitor.gitlab.net/dashboard/db/haproxy-stats?refresh...
But of course it is hard to mirror your repo to GitLab.com when GitHub.com is down, so maybe other sites are a better measure.
[1] - http://monitor.gitlab.net/dashboard/db/haproxy-stats?refresh...
[2] - http://monitor.gitlab.net/dashboard/db/haproxy-stats?refresh...
We might actually be at fault! That would be kinda cool.
I seem to remember there was a decentralized VCS which included issue tracking besides commits, but it never was mainstream.
It's not exactly less of a point of failure.