While this is still a massive problem, it does require a public fork at some point. So if you have a private repo that has never had a public fork, you should be safe.
(unforked repos that are forks are also affected.)
Yes, but only in very limited circumstances. If you:
fork a private repo with commit A into another private repo
add commit B in your fork
someone makes the original repo public
You add commit C to the still private fork
then commits A and B are publicly visible, but commit C is not.
If a public repository is made private, its public forks are split off into a new network.
Modifying the above situation to start with a public repo:
fork a public repository that has commit A
make commit B in your fork
You delete your fork
Commit B remains visible.
A version of this where step 3 is to take the fork private isn’t feasible because you can’t take a fork private - you have to duplicate the repo. And duplicated repos aren’t part of the same repository network in the way that forks are, so the same situation wouldn’t apply.
The second situation you listed is incredibly common, as the blog post explains.
While this is still a massive problem, it does require a public fork at some point. So if you have a private repo that has never had a public fork, you should be safe.
(unforked repos that are forks are also affected.)
Yes, but only in very limited circumstances. If you:
then commits A and B are publicly visible, but commit C is not.
Per the linked Github docs:
Modifying the above situation to start with a public repo:
Commit B remains visible.
A version of this where step 3 is to take the fork private isn’t feasible because you can’t take a fork private - you have to duplicate the repo. And duplicated repos aren’t part of the same repository network in the way that forks are, so the same situation wouldn’t apply.
The second situation you listed is incredibly common, as the blog post explains.