so what?

Private doesn't imply (common sense) that the original repository has power over any fork.

It does, otherwise github just wouldn't allow forking private repositories. 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. My guess is that forking a private repository is a feature github intended to be used where employees or contractors of an enterprise want to fork their employer's repository as part of their development activities for that employer. Github sees those forks as transitively controlled under the organization's access policies.

> 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 their perspective, there isn't a real difference between forking a private repo and making a private copy of a shared Google doc in your work account.

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.

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

Actually that's not really true, since your access to the original repository could still be revoked, and you are left with what you got.

Further, see sibling comment.

"My guess is that forking a private repository is a feature github intended to be used where employees or contractors of an enterprise want to fork their employer's repository as part of their development activities for that employer."

what you describe is "internal visibility"

https://docs.github.com/en/repositories/creating-and-managin...

That is the exact meaning, which does seem to be common sense. You can fork from a public, private or internal repo. Public is public and the fork won't get deleted when the repo removes you. Private deletes your fork, since it isn't your repo. Internal requires gated access.

for me the exact meaning for private is "available for a selected audience"

Exactly. That implies that when a person is removed from the selected audience, they lose access to the private code.

to my private repository, but not their own private repository.

like it happens when a public repo goes private: I don't loose access to my fork of the repo but access to the original repo

You are trying to construct a scenario, where you have the ability to elevate your own rights to somebody else's repo's contents. Name a computer system that intentionally allows people to do that. That similar to demanding that you can still send emails on a terminated email account from your prior employer.

If you want to continue your access to that private repo's source code, you now need to speak to them. They own it, not you.

I am not trying to construct anything. I just described what happens and what I expect.

"where you have the ability to elevate your own rights to somebody else's repo's contents."

This is not an accurate description. There are two repositories: the original repository, and the fork. Nowhere I want to to elevate my rights regarding the fork to the original repository.

" Name a computer system that intentionally allows people to do that."

If somebody sends me a word document per Email, I can edit it without someone else being able to delete the modified word document.

You keep trying to claim that a different person's private repo that you have forked has somehow given you ownership over the contained information. That's just not the case. Forking their code doesn't make it yours.

actually that is the point of a fork onto my account

GitHub doesn't allow you to make a public fork of a private repo, either. When you make a fork of a private repo, the resulting repo is constrained to have no broader access than the original.

"GitHub doesn't allow you to make a public fork of a private repo, either. "

where did I claim something like that?

I'm saying that GitHub consistently does not allow you to control access to a private fork. The original owners retain control.

how does this consistency manifest itself?

what about when the original owner publishes his repository? he doesn't control the visibility of the fork, does he?