Re: Yes and no
OK, here's the situation.

you fork an upstream repo, your fork is private

you commit something there that should not see daylight (keys to the Lamborghini or whatever)

you delete that commit to hide your sins

and now that commit is apparently still easily accessible from upstream. //

Re: Yes and no

Also - as far as I can see it's not actually possible to create private native GitHub forks of public repos in GitHub

The example they cite is when you have a private repo that will eventually become public, fork it to make permanently-private fork and then later make the original repo public. Anything commited to the still-private repo up until the point the first repo is made public, can be accessed from the now-public repo. (As long as you know the commit hashes, that is - but unfortunately they're easily discoverable.) //

The issue is that people are mentally modelling forks as "that's my copy of the repo, completely separate from the original" whereas in reality the fork is just a different interface to the same pool of blobs. Furthermore, while you wouldn't be able to access commits from another fork in the same pool of blobs unless you know the commit hash, github makes those commit hashes discoverable. //

Re: Yes and no
For the people downvoting me - you are aware how quickly AWS credentials accidentally exposed on GitHub are found and abused by attackers? Honeypot tests suggest 1 minute.

https://www.comparitech.com/blog/information-security/github-honeypot/

Note that at no point in the "what to do if you've exposed credentials" section does it say "delete the public repo in the hope that this will alter the past". Magical thinking.

Having played around with this on GitHub, I will say that the message on trying to delete a repo isn't explicit enough about the unexpected (if documented) behaviour. It really ought to have a disclaimer that says "If you're trying to delete commits you wish you hadn't pushed everywhere, this won't achieve it", and a link to a page describing what will actually help. //

What happens in Repo Stays In Repo
"It's reasonable to expect that deleting a commit tree that nobody else has yet accessed will prevent it from being accessed in future."

No it isn't. It's supposed to be a history. In a code repo, the ability to permanently delete past changeset data should be considered a bug or design flaw. The inability to lose history is the whole point.

Source code has no right to be forgotten, when it's in an SCM, because the point of the SCM is to remember.