For what it's worth, protected branches are pretty clearly listed as a "Github Pro" feature in their pricing page.
I agree that it'd be nice if they warned you about features you're using that will be turned off, but I don't think it's unreasonable to expect that people requesting downgrades understand which features are in which plan.
Maybe this could be suggested to GitHub's Paperclips project, to avoid future confusion?
Agreed. But there were a lot of people celebrating GitHub’s recent free account changes who were saying you no longer needed the pro account; this is a good reminder that you may need the pro account after all and do that check.
Downgrading an account for free should always be treated the same as upgrading an account for money. You gotta consider what you gain and lose in doing so before pulling the trigger without looking first.
Interesting, protected branches come free in GitLab. I never used Github to host my serious repos (I was using Bitbucket as soon as they started providing Git in addition to Hg).
I would suppose that as time passes by, Microsoft will improve the free offering avaialable on their service.
Did someone really just write a blog post on not downgrading an account without knowing what you're doing? Yes, you should not do that. You also shouldn't buy something without knowing what you're paying for, shouldn't vote for something you don't know what it is, you shouldn't eat stuff which might be poisonous but don't know for sure, you shouldn't cross a street without looking, gosh you certainly shouldn't drive a car with closed eyes not knowing where you're driving. Let's remind everyone of these things regularly, as this stuff is apparently not obvious anymore in 2019.
The OP clearly says, "It’s my fault for not reading the fine print more carefully."
They then further go on to say, "... when upgrading back to a Pro account, any branch protection rules you had before were permanently deleted when you downgraded to the free tier. They will all have to be recreated from scratch."
That is useful information, to me. People write blog posts about all types of things that are obvious to some and useful to others. Why be so nasty about this short post that seems to be useful to a lot of people? I guess that's 2019 for ya.
It's easy to ask snarky questions. That doesn't mean it's helpful or witty.
I admit that my rather sarcastic comment was a bit snarky. I am genuinely surprised though that people find this newsworthy. It's pretty obvious that if you're going to downgrade anything you'll lose something, no? I also find it very surprising that the OP was so astound that the lost triggers had to be re-configured if he was to upgrade again. Maybe it's just me, but this really felt pretty standard and extremely obvious, which is maybe why I wrote this rather snarky comment. Still wrong of me, so I take that feedback.
Amazing. I expected you to double-down and reply aggressively defensive, but that was a sincere, thoughtful reply. Thank you. Maybe 2019 isn't so bad after all. ;)
And I agree it's a fairly obvious risk if you stop and think about it, but it's not necessarily true that losing access to a feature, which is a reversible state, also permanently deletes all configuration data associated with that feature.
Your comment was direct, but fair, so it wasn't difficult to agree with you ;)
Regarding the branch protection feature, I can see it both ways, but I think overall I would have not expected them to be re-instantiated when upgrading to a higher tier again. Branches could have changed since then. I could have added more branches, deleted a branch which previously had the protection, then maybe created a new branch under the same name, etc.
Unless it's an immediate "I accidentally downgraded, revert all changes back again" action I think it's easier for GitHub to just let the user re-create what makes the most sense for them at the point of re-joining the higher tier. But like with most user features it's debatable...
GitHub is likely among the most widely used tools for HN users. Posting on HN, news that is relevant to such a majority of users on this platform, is a rather perfect use of HN as a dissemination platform. I read through GitHub's tiered service documentation after reading this article, and I couldn't find reference to branch controls being permanently deleted; so the OP was giving us very valuable experiential information, that was unattainable from GitHub. I really can't think of a better use for HN.
> Isn't the whole point of democracy "a large enough volume of ignorance will average out to something sensible"?
No, which is why the avdocates of liberal democracy from the very beginning have also argued that an an informed populace is critical to it.
It is the point that “self interest averaged out over the whole population equals public interest”, though, but greed and ignorance aren't the same thing.
No, it isn’t. The hope is that the ignorance averages out and the informed and motivated voters are the decisive factors. In practice democracy works better than if that model was correct because while voters have preferences that they will happily profess that reliably lead to bad outcomes they reliably vote out parties that are in power when things go badly. Politicians have an incentive to do things that will get them re-elected so gross economic mismanagement is not the order of the day, mostly.
> they reliably vote out parties that are in power when things go badly.
That's not at all the case, and even to the extent it is it is frustrated in separation of powers systems like the US, where the faction voted out will often be the one least responsible for the problems, since three are multiple factions in power at any given time a day the ignorance leads to blaming the wrong one.
What I wrote was too strong, you’re right. If there’s a huge fuckup the part[y|ies] in power are very likely to be voted out, the smaller the mess the less likely they are to be voted out, and that’s complicated by the tendency to want to throw the bums out when the incumbent government has been in power a long time. I agree entirely that fixed legislative terms and term limits are stupid ideas, along with separating the legislature and the executive. Parliamentary systems are better than presidential ones.
>Isn't the whole point of democracy "a large enough volume of ignorance will average out to something sensible"? :P
I hope not. A much stronger argument is that government should be by consent of its citizens. Otherwise, you get democracy-is-bad-because-people-vote-wrongly arguments (e.g. women vote too left-wing or white people vote too right-wing).
But isn't that a new behavior? Before I subscribed 1-2 year ago I read small characters pretty carefully, and in my memories in such case the behavior was to lock the previously private repo in a read-only state. Switching back to pro would then have restored full functionalities and setting on theses privates repos.
Automatically making it public seems like a new behavior, could someone confirm/infirm my memories?
If your account is downgraded automatically, Github will extort you for access to your private repositories. You don't get the option to just set them to public and stay on the free tier, Github simply forces you to pay up to get them back or lose them permanently.
Found this out when my old student account lapsed after I left college. Luckily, they screwed up and unlocked my private repos when attempting to charge me (there was no credit card on my Github account and never was -- nice work, Github) and I was able to pull my private repos and move everything to Gitlab.
Zero regrets. Extortion is never acceptable, especially when it's policy.
So if I don't pay the cable bill and my internet gets shut off, can I reasonably say I am being extorted by the cable company? That's a little hyperbolic. Plus, this isn't even how GH operates anymore, since they now offer free private repos.
Free accounts are now allowed unlimited numbers of private repos with limited collaboration.
But I would also not classify as removing access when you stop paying as extortion. You know when your account is paid up to. You would therefore know when you'd have featureful access to. It's not their fault you can't plan ahead is it?
I'm seeing people here chastising the OP for not fully knowing what he was getting into. But in all the excitement about the new free plan with private repos in January, GitHub failed to highlight other differences between the new free plan and the rebranded Pro plan.
We can blame the end user all we want, but GitHub could have prevented all of this.
Hosting private repositories on GitHub pages is another feature only available with the Pro plan. Figured this one out a few days after canceling my subscription.
I figured it out on the day my subscription lapsed, and someone created their own repository using my domain in their CNAME file. I had to wait until GitHub banned the user until I could set up the domain with GitHub Pages again.
Exactly. Git and github aren't backup tools. I always feel like github (and others) added to the git workflow things that are bolted on top of it and tie you to their platform.
Slightly offtopic, I have always considered a strange failure of git that branches are second class citizen in git, not worthy of the same versioning mechanisms as files. It is not unreasonable to expect a versioning system to be able to track the history of branches. And if I don't want to loose a file, just because it was deleted some time in the past, surely I also don't want to loose a branchjust because it was deleted. I don't buy the 'I want to be able to hide f-ups' argument.
Come the next garbage collect, the file changes in a deleted branch are forgotten. If I don't want to loose changes, garbage collect shouldn't be a thing, because there is no garbage, just history.
You can disable automatic garbage collection if you want to. You could also have "versioned branches", but you'd have to do it yourself, using either branches or tags. Tagging the head of a branch just before you rebase would do it.
As I recall the GC will only touch things that have been deleted for some time (a month?), that's a long time to correct accidental deletions.
Garbage is created every time you amend or rebase. What is the value of keeping around commits that are unreachable through any branch, containing typos in the commit messages?
It seems to me that source control can really bring out the hoarder in people, a fear of throwing away anything because you might need it later. I prefer it when the commits in a repo tell a story, but keeping everything that didn't end up on the master branch... why?
> As I recall the GC will only touch things that have been deleted for some time (a month?), that's a long time to correct accidental deletions.
That is what I mean by second class citizen. The same logic doesn't apply to deleted files in a branch. If I delete a file it may not be accidental at all, and still I expect it to be accessible and not be considered 'orphaned', 'garbage' or similar. Why doesn't git throw away everything that is older than 90 days? (the default for gc)
It amazes me how many people just don't grasp the "distributed" part of git. No repository is special and it's trivially easy to make a new one somewhere.
I downgraded too, and noticed GitHub Pages stopped working (the content is still there, but they don't rebuild - although they did for a little while after downgrading). It is clearly marked as a Pro feature, I just hadn't considered that the free private repos would be more restricted.
It's not a big deal to me, I'll probably just make the repos public.
Just private repos. When you look at the GH pages section it says "Make this repo public to enable GH Pages" or something. Your existing site still serves, but it doesn't build anymore.
To some it might seem weird, but in cases like this having even your repository configuration in Configuration management makes sense, for example using Terraform[0]. Of course you have a chicken-egg problem for that first repo that actually contains your CI code. But if you just apply common sense that problem doesn't really exist.
With repositories it is just so easy for little configuration drift to slip in. A branch you forgot to protect. A user/group that should no longer have write permissions, etc.
Not needed. They already know how to use special repo branches for special things. See e.g. gh-pages and yourproject.wiki.git. They could _trivially_ have yourproject.issues.git etc, except that not doing that gives them a competitive moat making it harder to migrate away.
Google's Gerrit Code Review stores its special permissions and such in a meta/ references namespace, which has restricted permissions. So instead of refs/heads/ for branch names, there's refs/meta/*. The meta space has config files specifying the permissions.
Also the config and permissions changes are logged, because they're git commits too.
The same could be done without forking git. One could also just have a parallel git repo with config files.
If you have a job where you arent allowed to commit directly to master / development branches this is probably how they enforce it. It keeps juniors from pushing bad code without peer review. It forces developers into doing PRs instead. Protected branches are the first thing we setup when we make a new repository at work once we hit the "getting good enough for production and autobuilds" stage of development.
> It keeps juniors from pushing bad code without peer review.
It keeps all developers from pushing code without peer review.
(In my experience, it’s just as often senior devs pushing broken code because “this was a simple change, why does it need review?” and it in fact being broken. Furthermore, doing PRs is not solely to “check for mistakes”, they are also used for knowledge sharing, among other reasons)
Yeah but the concept of this post revolves around individual developer github account (not an organizational one). What circumstances would you be protecting your own private repo?
You can still use the same ruleset to force yourself to write code independently with a sane process though. I put repository rules on my personal private repositories on BitBucket and GitLab. Once you're used to a specific process and it works nicely for you, it makes sense to repeat. This way you don't ever pollute your main branches with in-progress code by mistake.
but you're talking about a company or corporate environment where, if they do use Github, it ain't you who is going to be in charge of the account and making a decision like OP did.
I agree, and quite like Gitlab, but Github's recent decision to allow free private repos has surely put a bit of a dent in Gitlab/Bitbucket's marketshare expansion - many people were using those services instead of Github just for that feature.
Git won in the same sense that chrome won or windows won, there's value in having alternatives and I would like to have the option of mercurial in more settings.
I am not advocating for use of git or mercurial, use whatever suits your needs! But I think having a platform like bitbucket support alternatives to git is a big plus for developer freedom to chose.
I think another interesting VCS is probably Fossil. It's very self-capable and self-contained. I wish it were a little more commonly used, but git or mercurial is where it's at I suppose. I keep meaning to use mercurial more, maybe I should for my BitBucket projects, it's not like it makes much difference since JetBrains IDE's handle the under the hood version control commands.
There is a more serious impact of downgrading if you were hosting a static website from a private repository on github with a pro account. Apparently that's not supported with free account. My personal website went down as soon as I downgraded to free. I didn't mind making the repo public, so it was an easy fix, but may not be same for others.
Using gitlab and bitbucket for my personal repos on their free tiers have solved a lot of problems for me. Also, a lot of features are way ahead of github on these 2 platforms including CI/CD, Code reviews, and other tooling.
It's fairly common to do `git push --force` (or hopefully `--force-with-lease`) after operations like rebasing. This overwrites the remote history, so can easily lose work. Many people set some branches as protected, so they can't be force-pushed over accidentally.
Isn't it a pretty bad idea to have a workflow which involves --force? If it's to keep history tidy, why not just develop on a separate branch and do squash merges?
I'll admit I haven't used git in extremely complex circumstances, but I've always viewed --force as something you do only if you really mess up, such as pushing secrets (and that should obviously be in addition to invalidating those keys and generating new ones).
Working on a separate branch may still require periodically bringing in changes from master (eg. to resolve conflicts). The options are either a) a merge commit or b) a rebase. A rebase will require a `--force` push. Some people prefer merges, but personally I prefer rebasing - I like to keep my full history even when merging back to master, since it's not a lot of extra effort and it can be useful when tracking down issues in old code :)
the rebase strategy involves force-pushing to your topic branch and then ff-merging to master (or develop, or whatever). some people love it, some hate it, but force pushing is a necessary part of the strategy if the master branch has had new commits since you created your branch.
yes, force pushing can be dangerous, which is why (when you use the rebase strategy) you usually protect certain branches. force-pushing should only happen on your short-lived topic branches.
People aren't talking about force pushing to master, they're talking about force pushing to another branch, but with master unprotected, and therefore, by accident, force pushing to master as well.
> i will communicate a force push on master to the whole team and will disable protection temporarily
Isn't that exactly what this point was about? You have branch protection enabled for master because you think it's a good idea to avoid accidental force-pushes. These comments were exactly about not having the ability to protect branches.
I'm not really sure what you're arguing for/against.
As ComputerGuru and Schnouki explain, one can use the reflog. For anyone who's intimidated by the reflog, perhaps my recipe under "All the things your branch has ever been" will help.
I agree that it'd be nice if they warned you about features you're using that will be turned off, but I don't think it's unreasonable to expect that people requesting downgrades understand which features are in which plan.
Maybe this could be suggested to GitHub's Paperclips project, to avoid future confusion?