Live data from Hacker News

Tell HN: GitHub will delete your private repo if you lose access to the original

news.ycombinator.com

201–210 of 294 posts

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#201
post #35

Earlier quoted context omitted.

If you worked at a company and had a fork of a private repo that company maintained of some software... do you want employees who have left to have their access to the repos removed? or an email that says that it will be removed?

> had a fork of a private repo This is the real anti-feature. You should only be able to fork a private repo using an account that is directly managed by the organization that owns the repo. That way when you revoke access to the user they automatically lose access to the fork. It's super weird that it's common to use the same account for work and non-work stuff on GitHub (myself included).

Yes, because GitHub doesn't support organization users (maybe you have to pay?) so the thing is that you use your personal account. That is fine, since the real account is the membership to the organization. The only thing is the stuff of private repo: if there is this unintuitive behaviour it shouldn't be allowed to fork private repositories at all.

Or the fork should not be deleted, but it should be made in a way that it's equivalent to a pull and then push to another repo, that is if you loose access to the original private repo you can still see your code, but you can no longer pull from the upstream private repo. I think this is a problem on how data/permissions is represented at low level in a repo, so if this is the case and cannot be fixed they shouldn't allow private repo fork at all.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#202
post #95

GitHub also blocks their built-in fork UI functionality when the original repo's owner uses the site's "block" feature against you, which doesn't align with my expectations. Ironically, anyone affected by this poorly implemented blocking behavior (and thereby copying the full repo instead of forking) would be protected from this bug by the OP.

This is because forking is a social feature. If the origin repo is unwilling to accept pull requests from you, there's no reason to let you fork.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#203
post #195
post #167

I'm getting a sense like something is not right at GitHub, maybe it's just a coincidence but just in the last week I saw GitHub breaking their CI (causing many runs to fail due to a billing bug), then the checksum tarball issue and now this.

This is how private forks have worked at GitHub forever.

[deleted]

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#204
post #200

Earlier quoted context omitted.

> If they did allow that, and retained no control over the forked copy, now you can ride a coach and horses through the access control to a private repo by simply forking it when you have access. ...which you can still trivially do if you use git to make the copy. And then your github repo will be immune to this kind of deletion. So common sense says to me this should act similarly.

> ...which you can still trivially do if you use git to make the copy. If you want to steal code from your former employer it's your business and your legal jeopardy. GitHub can't do anything about that. They can remove access to the copies they're storing for you, though. GitHub has a weird model where they encourage using the same account for personal and professional work, which causes this kind of ambiguity. From…

It's not about wanting to steal anything. It's that making a copy is trivial, so there's no point in worrying about how you can "you can ride a coach and horses through the access control".

Don't worry about the barn door when there is no side on the barn.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#205
post #34

Earlier quoted context omitted.

> If the YouTube algorithm nukes your account and all your videos, you should be ready to upload them to a new account. Same with anything else digital. Do you know if this is a common occurrence? Also, I'm only a YouTube viewer and am not familiar with all the creator tools, problems, communities, etc. But would a creator really re-upload all their back-catalog if deleted? Just to try to get back to views and things…

A few weeks ago, youtube changed their swearword policy. A creator I follow basically had to delete half their channel or risk termination.

Huh, that probably explains... I was in a youtube rabbit hole right around then when some videos suddenly wouldn't load, turned out that I might've been the final viewer of the (small) channel that had had been banned at that moment. I was wondering what the chances were.

edit: Seems like it. The channel[1] name probably raised some new flag, and Google did its thing. Seems fair, it's not like a reasonable moderator would know of a concept of a second chance or anything.

[1] https://web.archive.org/web/20181123103308/https://www.youtu... https://web.archive.org/web/20220624154617/https://www.youtu...

// Ah, that channel was a pretty interesting part of the rabbithole of net culture-related parody too - rare to see collaboration like that

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#206
post #7

I think this is under the assumption of "employee has a private fork of the company repo, then leaves, employee should not keep the fork" So when "removed as a collaborator" which apparently includes the original being deleted, you lose access to the main repo and all forks, even yours. As if leaving a company.

Microsoft does this a lot, where they assume that rules that apply to their own organisations apply to all organisations in precisely the same way. If a Microsoft IC leaves, they should lose access to all Git repos, including forks. If Joe Random open-source contributor is removed from an open source repo's access list, their fork shouldn't be wiped. But Microsoft has One Rule To Rule Them All, so they won't make exc…

This behavior was not introduced to GitHub by Microsoft.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#207
post #174
post #163

Earlier quoted context omitted.

Did you forget the part where this code is MIT-licensed? Yes, they don't own it, but the code is still 'theirs' to keep forever as they see fit.

The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is. The person may be able to find the original code that was MIT licensed…

OP wrote

> That was an MIT-licensed open source project I worked on years ago.

which to me implies that OP also received the code under the MIT license and not some other license.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#208
post #200

Earlier quoted context omitted.

> ...which you can still trivially do if you use git to make the copy. If you want to steal code from your former employer it's your business and your legal jeopardy. GitHub can't do anything about that. They can remove access to the copies they're storing for you, though. GitHub has a weird model where they encourage using the same account for personal and professional work, which causes this kind of ambiguity. From…

It's not about wanting to steal anything. It's that making a copy is trivial, so there's no point in worrying about how you can "you can ride a coach and horses through the access control". Don't worry about the barn door when there is no side on the barn.

My point is that GitHub does not personally want to have a hand on the reins, or whatever metaphor we're doing here. A private fork is a copy of the original code that GitHub is holding onto. A clone on your personal computer or server or printed out on paper tape is a copy that you are holding on to.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#209

I have to assume that the original repository was private when you forked it. If it was public, and then made private, then this should not happen. If the original code was "open source", then why exactly was it in a private repository? Putting "MIT licensed open source" into a private repository is not publishing that source code for the world to use. It sounds like nothing weird happened here other than this compan…

Open source doesn't necessary mean that the code has to be share publicly on the internet, let alone on a GitHub repo! This is a common misconception. You can of course also decide to sell an open source software, that is have other pay you to obtain the software source code with an open source license (of course this person then can share the code, or even sell it to others legally, so it's not commonly done). I can…

I have no misconception of what open source is, if you want to put your foot near this foot gun intentionally by paying GitHub to host code you've open sourced (while telling no one outside your org that you've open sourced it) that's fine.

A common misconception is that publishing a public repo comes with obligations to add tests, documentation and whatever.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#210

If you have a Raspberry Pi wasting away in a drawer[0], I strongly recommend installing Gitea or Forgejo and mirroring all the repos you like (i.e. the ones you contribute(d) to and/or starred, not just on Github too!). You set it up once and it will sync in upstream changes as often as you like (default is daily) 0. Or a homelab, or a cheap 256MB VM, or a NAS that can run docker containers, or an old Chromebook: any…

I wonder if there is an efficient way to do direct incremental git-to-S3 backups, or if you have to do this, run a Git mirror and do regular filesystem-level backups of it.
Post reply on HN