I say this every chance I get, but Github can and will hold your code ransom if your premium account lapses while you still have private repos. They do not give you the option to set those repos to public, they require you to pay money to regain access.

Maybe you can have them switch the repos to public if you go through their support, but Github doesn't offer that in their ransom note, and that would be an unacceptable solution, anyway.

Whether or not this is a risk to a given developer (or their company) is irrelevant to me, because they still have policy that allows them to hold code hostage for ransom, and that should make Github a complete non-starter when deciding on an SCM host.

Calling it a randsom note is a tad dramatic. You pay them for the service of private repos. If you stop paying, you stop getting the service.

Just like every other business ever.

Generally you are correct: service is paid for -> stop paying -> stop service. However, Github has a free tier for public repositories. Why can one not convert the repository to public then?

I like how Dropbox handles this. If your paid membership is cancelled and you are using more space than the free tier, they don't delete your files, just make them read-only. You can view or download them, but if you want to upload or update something, you have to buy premium or bring your space use within free tier limitations.

People may put all manner of things in private repos that they don't want to be made public, so github shouldn't just expose them to the outside world.

That doesn't mean they couldn't just offer a button to make them public after the fact, I don't think anyone was suggesting to make them public automatically...

GitHub shouldn't make them public, for sure. But people should.

Because github can’t make that decision. It’s your responsibility to convert it to public. There could be sensitive information in the private repos.

...hence why they should give you that option if your paid account expires. It feels like people are being intentionally obtuse in this thread

Nope, that is exactly what it is. There is no reason not to give read-only or export-only access to private repos if your account is locked. Otherwise just delete the whole thing.

If anyone has ever cloned the project, Github cannot hold your code to ransom because you already have a copy of it and the whole history including commit messages. That is the beauty of git.

Github do have your issues and un-merged pull requests "to ransom", though. Make sure to back those up if they are important.

How can they hold your local clone of the code hostage?

A sane option is to deny GIT access while still allowing the primary account to download a copy of the repo for a set amount of days.

Instead they play "data roach motel" and hold your data hostage. Very uncool.

Pay your bills. I cannot take the idea that they're holding anything "hostage" when the whole thing is that you're not paying your bill. If you don't pay your car bill, they'll take it back.

7 bucks a month is hardly ransom. it would be better than automatically making private repo's public when you stop paying

> 7 bucks a month is hardly ransom.

You do not know other peoples' situations. And strictly speaking, demanding money to access your data is ransom.

> it would be better than automatically making private repo's public when you stop paying

False equivalency. I already said that "disabling repo and allowing primary user to download" was acceptable. I said nothing about private->public.

This whole situation only reaffirms my distrust in all cloud services.

EDIT: Seriously, -1 ? The user's data is sacrosanct. You disable most functionality, but you never, I repeat never delete data or make it irretrievable within a envelope of time for recovery. The only exception to that is if the user explicitly requests a permanent deletion - then you do so after appropriate warnings.

You're being downvoted for they ridiculous hyperbole of using the terms "ransom" and "hostage" for the situation, when it's just that you didn't pay your bill, so you don't get access to the service. Any web host would do the same, as would any other business. You don't pay your bill, you don't get the service. Why is that so hard to comprehend?

I think that's because the service is hosting the data, not the data itself. Holding onto the data which you (expect to) own is pretty much akin to a person taking care of a pet for money and when the money is not paid, keeps the cat. It's the obvious solution - the cat-sitter doesn't have any other leverage here - but Github does have other options than holding onto the cat.

A better parallel would be storage lockers. And there, if you stop paying eventually they cut the lock off and sell your stuff.

Has anyone created a service that you auth in through GitHub and it backs up all your repos to S3 or Dropbox or something? I'd pay a few bucks for something like that.

Edit: I found backhub.co. Unfortunately their pricing is per-repo and my usage model involves lots of tiny repos.

Set multiple urls for one remote using `--push`

https://git-scm.com/docs/git-remote#git-remote-emset-urlem

and you are about done.

This is only a partial solution, right? Services such as Backhub.co also backup your issues: https://backhub.co/features/backup-github-issues/

(we have 1000+ closed issues in our project, nice to preserve)

Right. The service is certainly expected to do more. Was mostly addressing the issue of mirroring the data to dropbox. But even then my "solution" only saves whatever you do locally. So if you merge PRs through github, it wouldn't get mirrored.

If you have self-deployed Gogs (which is a smallish OSS GitHub clone) you can easily set it to mirror other repositories periodically. Very useful for backups.

Also simple to self-deploy since it's essentially a single service written in Go.

Check out Gitea, which is a community managed fork of Gogs.

If you're writing research software you can backup to zenodo (i.e. CERN) for free.

>Has anyone created a service that you auth in through GitHub and it backs up all your repos to S3 or Dropbox or something? I'd pay a few bucks for something like that.

So you'd pay money for a tool that copies your data, but not simply pay the money to access said data?

This doesn't make any sense at all.

I am beginner so bear with me. I learnt git 2 years back and always end up using the same set of commands and never anything new which lets me work very smoothly on projects. I read a lot of blogs to understand how git works and how useful git reflog is. I was/am often confused about what is offered solely by git and github as these two are two different things. Is fork/PR/Issues native to git? I still don't have an answer.

Git is to GitHub what e-mail is to Gmail. GitHub is a specific service that offers git hosting and some extra goodies.

As for what is part of what, anything you do with the ‘git’ command is part of git. Anything you have to do on github.com is not.

>Anything you have to do on github.com is not

Just to be clear we can create a branch on github as well as on git though I am not forced to do so on github. This maybe confusing for a beginner as both provide branching.

Yeah, I nearly said “anything you do on github.com,” but then remembered there are things you can do both ways.

Unless you install GitHub's hub and alias `git` to `hub` as suggested in the install doc—then some of what you can do in Git is GitHub specific

Forks are clones that live on GitHub, with some access control.

PRs are native to GitHub, but I can send you an email Requesting that you Pull from my remote. The Linux kernel team still emails patches I think.

Issues are a GitHub thing.

Thanks. This answers it. It looks like whenever git is introduced to someone is always through github. I think this is why most people assume a different picture of git than what it actually is. I think this demarcation between git and github must be clearly stated.

Github is just the end point where the program git pushes your code for storage and viewing.

There are plenty of other alternatives, including ones you can host yourself, the most popular that I've seen being GitLab and BitBucket.

None of those things are native to git. The command line git tool’s help options open up the git manual. It is pretty comprehensive; so if the topic is missing, it’s probably a github feature. (Also, things like ‘git checkout --help’ open up subsections of the manual)

Git is a decentralized source control system, also known as a DVCS (distributed version control system).

"GitHub" is essentially just "git" on some someone else's computer with a bunch of extra features.

>"GitHub" is essentially just "git" on some someone else's computer with a bunch of extra features.

The comment below you answered my question : PR/Issues are native to github.

I'm not sure what you mean by "PR/Issues are native to github", there are other choices for code review for self-hosted git:

https://www.gerritcodereview.com/

Incidentally Gerrit predates github.

"GitHub PRs/issues are native to GitHub". If you switch to Gerrit, the code commits themselves follow, but the PRs and issues don't. They're only on GitHub.

I wouldn't point to gerrit as an example of self-hosting git. Gerrit's "patchsets" and "change-id"s concepts, as well as the weirdo remote push refs, really turns the git experience into something... very different. It's very far from both how "normal" git commits and tracking branches workflow work, and from github/gitlab/bitbucket's pull-request/merge-request style.

How is it not a an "example of self-hosting git" when it's built on top of git?

I understand from your comment that it's not your preference but that doesn't mean its not a self hosted git solution.

Because the gerrit workflow is extremely different from all other common git workflows (which is to say, you build a set of commits in your own branch or fork and ask the maintainer to pull it). Gerrit actively encourages you to rebase and rewrite (and lose) your development history in the pursuit of a "perfect" one-hot non-merge history patchset, which actively loses information about the context of where your changes where applied.

The problem with submitting a rebased branch is that while there are no apparent merge conflict and your changes appear to have been developed on the tip of master, your changes may actually have been developed on a much older version of master. Builds may appear to compile fine but they might not make sense - when you discard and rebase the context of commits, you lose important information.

As usual, cloud services are other people's computers, but it seems devs now keep forgetting about it.

Yet, most users are content with GitHub being the sole owner of their issues, pull requests, code review, wiki...

GitHub wikis are just git repos themselves, and I clone mine. It's easier to edit them locally, too.

As for issues, I've suggested to GitHub that they make them available via git, and they said simply "I have passed your suggestion on to the team to consider adding the ability to clone Issues". I don't think they realize how nerve-wracking it is to put any data at all in GitHub issues. Even their recommended backup software is out of date and doesn't back up Issues completely.

This is typical. Most businesses don't duplicate their workflow stuff to a parallel system because database backups are sufficient.

GitHub, even with relatively recent issues and downtime, has better infrastructure and skilled personnel than most companies hosting their own instances of these services on some reclaimed box.

Even if they have great infrastructure, this article is evidence that they can still take you down at any given moment if they so much as feel like it.

You need those database backups.

Or you can pay them and not violate their terms. Outrage over GitHub admin actions is loud, but for the 99.999% of cases everything is fine.

> not violate their terms

I haven't checked GitHub specifically, but most of those terms include, "and we can ditch you any time for any reason, maybe with 30 days notice if you're paying"

Not to mention it's also common to include "we can change the terms at any time" - and of course, there's also the fact that this issue in specific has nothing to do with a ToS violation, but with permissions on the parent repository, by relying on them with no backups you're not only subject to their staff's whim, but to the whim of any bugs or "features" in their code.

If you want to take advantage of their infrastructure, that's fair, I understand, but at the very least, run some tooling to backup issues, pull requests, wiki pages, etc on a regular basis.

With 26 million users, five nines is not very reassuring.