Live data from Hacker News

Think Twice Before Downgrading to a Free GitHub Account

blog.jaredsinclair.com

51–60 of 102 posts

Re: Think Twice Before Downgrading to a Free GitHub Account

#52
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.

[0] https://www.terraform.io/docs/providers/github/r/branch_prot... https://www.terraform.io/docs/providers/type/vcs-index.html

Re: Think Twice Before Downgrading to a Free GitHub Account

#53
post #48

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…

> shouldn't vote for something you don't know what it is Isn't the whole point of democracy "a large enough volume of ignorance will average out to something sensible"? :P

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.

Re: Think Twice Before Downgrading to a Free GitHub Account

#54

Earlier quoted context omitted.

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)

> It keeps all developers from pushing code without peer review.

This is true, I don't know why I went with juniors.

Re: Think Twice Before Downgrading to a Free GitHub Account

#55

honestly though... how many everyday devs actually use something like this?

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.

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?

Re: Think Twice Before Downgrading to a Free GitHub Account

#57

Earlier quoted context omitted.

> 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)

> It keeps all developers from pushing code without peer review. This is true, I don't know why I went with juniors.

Because junior is a state of mind not an age

Re: Think Twice Before Downgrading to a Free GitHub Account

#58
post #48

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…

> shouldn't vote for something you don't know what it is Isn't the whole point of democracy "a large enough volume of ignorance will average out to something sensible"? :P

>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).

Re: Think Twice Before Downgrading to a Free GitHub Account

#59

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.

Re: Think Twice Before Downgrading to a Free GitHub Account

#60
post #19
post #16

What? What is he doing that it makes him fear code loss?

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.

Its not and it shouldn't.

I do often rebase on my local branch but i will communicate a force push on master to the whole team and will disable protection temporarily.

If thats the only reason, he should overthink his workflow.

Post reply on HN