Github could do better by warning the repo owner when they delete a private repo. Github could ask the repo owner if they want to convert it to public first (a "set it free" option) or otherwise give the option to avoid deleting the forks of others.
Essentially what I just said is the same as what you did. The private modifications cannot be assumed to be under the same license as the original software. Gitlab has no way of knowing all these details, and have promised to keep private repos private, so their current policy is the correct one.
What's next? Should we all install spyware on our computers and let GitHub automatically delete local copies of forks as well?
GitHub and the company/person, who deleted the original private repo, should inform the owner of the fork that the main repo was deleted. If need be, company/person can request fork owner to delete their private fork and local clone as well.
First off is the fact that forking a repo is often a necessary step in contributing to project if you don't have push permission, so these forks will be created during the normal development processes, not necessarily because the employee was intentionally trying to save off their own copy. So it is perfectly normal for the employer to consider those forks to be something it should own and manage, just like it would on an on-premise installation.
On the otherhand, github still encourages people to use a single account for both personal use and work[1]. Naturally the employees reasonably consider all the forks that are in their personal account to be something that they should own and manage. So you end up with situtations like this.
The lesson - mixing work and personal accounts/computers/devices is a horrible idea regardless of what Github says. Employers shouldn't allow it, and employees should avoid it even if allowed. Then both will have a clear idea of who owns and controls what.
[1] https://docs.github.com/en/get-started/learning-about-github...
With that in mind, if you fork an organizationally-managed repository, there's a good chance the owner doesn't want you to continue to have access to that codebase if you're no longer a part of the organization. And the local copy? Well there's a good chance you were only allowed to clone the repo on an IT-managed device with specific 2FA policies and some kind of agent/config to prevent/reduce data exfiltration from that device.
Is it a perfect system? Hell no. Data leaks, that's part of life. And I'm with you that it certainly could be more user-configurable.
But it's also extremely well-documented behavior[1], and seems like a key design choice that GitHub made a long time ago to protect the owners of private repos. Ultimately, if you don't care about who has access to your code, you signal that by making the repo public. Or by telling your private collaborators to make sure they hold on to a local copy.
[1]: https://docs.github.com/en/pull-requests/collaborating-with-...
I disagree. I expect a (i.e. my) fork to be independent of the original repository, no matter if it is private or not.
It's enough if a fork of a private repository is private then too.
Instead I prefer to use a "git" fork. I just clone it and upload it to my own repo. Assuming the license permits of course.
It's unfortunate because not having a "real" fork makes it harder to send pull requests and track the upstream. But it's sometimes necessary to get around stupid github policies.
This has been the case on github.com for over a decade, and I am slightly shocked that people don't know this. I guess the root of that is that I am surprised that this has not bitten more people than it has.
People assuming things are a certain way and never checking to verify that are by far the greatest source of "I shot myself in the foot" statements that will ever be known.
nope, that's not true:
"GitHub will detach private forks and turn them into a standalone private repository. For more information, see "What happens to forks when a repository is deleted or changes visibility?""
" If the parent repo is public and switches to private, so do all forks."
This isn't true either:
"GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private."
In these cases, exactly what I would have expected happens.
I linked directly to the documentation about "Fork" in another comment.
https://en.wikipedia.org/wiki/Fork_(software_development)#Et...
If this is acceptable because the original version it's a private repository that is unrelated, what we are discussing is the meaning of the word itself.
Regarding forking a private repository with a public repository, it's a corner case for sure. In my opinion it's best to forbid forks of private repositories at all, and forbid to make a repository that has forks private, than to create problems like the one of the user in this topic.