This is documented at: https://docs.github.com/en/pull-requests/collaborating-with-...
[1] https://docs.github.com/en/pull-requests/collaborating-with-...
This makes sense. Thank you for clarifying that important detail. It seems to be missing from the parts of the discussion I've read here.
You have access to many private company files. After you leave the company, the company is obligated to send you copies of all of the files because you may have linked to them. After all, you could have made personal copies of all of the files, so you should still retain access through links.
"If a public repository is made private and then deleted, its public forks will continue to exist in a separate network."
https://docs.github.com/en/pull-requests/collaborating-with-...
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
― Douglas Adams, The Hitchhiker's Guide to the Galaxy
This is unexpected behaviour from Github here which may (and has, by the anecdote of OP) cause permanent data loss. Documentation is not good enough, as users should not have been expected to have read the entire documentation.
On that note, an organization admin can _directly_ delete your private fork without even deleting the source repository if they want. GitHub's permission model is fairly direct that private forks you make through your membership in an organization are more the organization's property than the forker's.
This is exactly how it works today already. If I try to delete a private repository people have forked, I see the following:
> We will also delete all 4 forks since this is a private repository.
Clicking on the delete button, again:
> Unexpected bad things will happen if you don’t read this!
> This will also delete all 4 forks since this is a private repository.
> [type name of repository]
To this day I thought that the "fork" concept was only a relationship at the level of UI, but as I see it has a logic in it, that is the fork depends on the original repository even for permissions, and that to me is surprising!
If the org doesn't work this way, it can disable forking so that it's not allowed at all on the repo (or org-wide), like you said.
I know this isn't common but I actually use a unique user for my company "myname-company"