Live data from Hacker News

Think Twice Before Downgrading to a Free GitHub Account

blog.jaredsinclair.com

91–100 of 102 posts

Re: Think Twice Before Downgrading to a Free GitHub Account

#91
post #40
post #39

Earlier quoted context omitted.

Also Bitbucket supports mercurial repositories, which is a shame has so little support on the other big platforms.

Git won though. I'm not especially a fan of git, but at this point advocating for mercurial is tilting at windmills.

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.

Re: Think Twice Before Downgrading to a Free GitHub Account

#92
post #56
post #42

I think it's stupid that GitHub stores (meta-) data in a place that's not governed by git. Everything should be in git.

Are you suggesting that GitHub should fork git to add new features?

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.

Re: Think Twice Before Downgrading to a Free GitHub Account

#94
post #20

Earlier quoted context omitted.

git push --force It doesn't actually delete the commits, but you can't find them anymore if you don't remember the hash of the former head commit of the branch

`git reflog` is your friend; provided not too many operations have since passed.

[deleted]

Re: Think Twice Before Downgrading to a Free GitHub Account

#95
post #20

Earlier quoted context omitted.

git push --force It doesn't actually delete the commits, but you can't find them anymore if you don't remember the hash of the former head commit of the branch

Unless you use git reflog.

But you can't run it on GitHub's side.

Re: Think Twice Before Downgrading to a Free GitHub Account

#96
post #69
post #19

Earlier quoted context omitted.

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…

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

Re: Think Twice Before Downgrading to a Free GitHub Account

#97
post #60
post #19

Earlier quoted context omitted.

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.

> Its not

It's not common to rebase?

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

Re: Think Twice Before Downgrading to a Free GitHub Account

#98

Earlier quoted context omitted.

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…

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 o…

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.

Re: Think Twice Before Downgrading to a Free GitHub Account

#99
post #18

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.

I have a free GitHub account and also have GitHub Pages for my blog, which is developed in one of my public repos. Do you mean some specific additional features for GitHub Pages, such as a vanity URL, or building from private repos?

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.
Post reply on HN