4 ms·

There seems to be no such thing as a "private fork" on GitHub in 2024 [1]: > A fork is a new repository that shares code and visibility settings with the upstr

There seems to be no such thing as a "private fork" on GitHub in 2024 [1]: > A fork is a new repository that shares code and visibility settings with the upstream repository. All forks of public repositories are public. You cannot change the visibility of a fork. [1] https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-permissions-and-visibility-of-forks#about-visibility-of-forks https://docs.github.com/en/pull-requests/collaborating-with-...

Manuel_D 2y ago
Not through the GitHub interface, no. But you can copy all files in a repository and create a new repository. IIRC there's a way to retain the history via this process as well.
- make3 2y ago
  That's not the GitHub concept / almost trademark of "fork" anymore though, which is what your parent was talking about
- a1o 2y ago
  I mean it's git, just git init, git remote add for origin and upstream, origin pointing to your private, git fetch upstream, git push to origin.
- mckn1ght 2y ago
  You can create a private repository on GitHub, clone it locally, add the repo being "forked" from as a separate git remote (I usually call this one "upstream" and my "fork", well, "fork"), fetch and pull from upstream, then push to fork.
- shkkmo 2y ago
  All you should have to do is just clone the repo locally and then create a blank GitHub repository, set it as the/a remote and push to it.
- JyB 2y ago
  That’s beside the point. The article is specifically about « GitHub forks » and their shortcomings. It’s unrelated to pushing to distinct repositories not magically ´linked’ by the GH « fork feature ».
ff7c11 2y ago
A fork of a private repo is private. When you make the original repo public, the fork is still a private repo, but the commits can now be accessed by hash.
- CGamesPlay 2y ago
  According to the screenshot in the documentation, though, new commits made to the fork will not be accessible by hash. So private feature branches in forks may be accessible via the upstream that was changed to public, if those branches existed at the time the upstream's visibility changed, but new feature branches made after that time won't be accessible.
  - pcthrowaway 2y ago
    OK but say a company has a private, closed source internal tool, and they want to open-source some part of it. They fork it and start working on cleaning up the history to make it publishable. After some changes which include deleting sensitive information and proprietary code, and squashing all the history to one commit, they change the repo to public. According to this article, any commit on either repo which was made before the 2nd repo was made public, can still be accessed on the public repo.
    - reisse 2y ago
      > After some changes which include deleting sensitive information and proprietary code, and squashing all the history to one commit, they change the repo to public. I know this might look like a valid approach on the first glance but... it is stupid for anyone who knows how git or GitHub API works? Remote (GitHub's) reflog is not GC'd immediately, you can try to get commit hashes from events history via API, and then try to get commits from reflog.
      - marcosdumay 2y ago
        Yes, even though I expect there to be people that do exactly what the GP describes, if you know git it has severe "do not do that!" vibes. Do not squash your commits and make the repository public. Instead, make a new repository and add the code there.
rkagerer 2y ago
Am I the only one who finds this conceptually confusing?
- rocqua 2y ago
  Nope, me too. The whole Repo network thing is not User facing at all. It is an internal thing at GitHub to allow easier pull requests between repo's. But it isn't a concept git knows, and it doesn't affect GitHub users at all except for this one weird thing.
  - brazzledazzle 2y ago
    I may be recalling incorrectly but I seem to remember it having some storage deduplication benefits on the backend.
  - tedmiston 2y ago
    > Nope, me too. The whole Repo network thing is not User facing at all. There are some user-facing parts: You can find the fork network and some related bits under repo insights. (The UX is not great.) https://github.com/apache/airflow/forks?include=active&page=1&period=&sort_by=stargazer_counts https://github.com/apache/airflow/forks?include=active&page=...
itsgabriel 2y ago
Funnily enough the docs are wrong, the GitHub CLI allows changing a forks visibility https://stackoverflow.com/a/78094654/12846952 https://stackoverflow.com/a/78094654/12846952

Manuel_D 2y ago

Not through the GitHub interface, no. But you can copy all files in a repository and create a new repository. IIRC there's a way to retain the history via this process as well.

make3 2y ago
That's not the GitHub concept / almost trademark of "fork" anymore though, which is what your parent was talking about
a1o 2y ago
I mean it's git, just git init, git remote add for origin and upstream, origin pointing to your private, git fetch upstream, git push to origin.
mckn1ght 2y ago
You can create a private repository on GitHub, clone it locally, add the repo being "forked" from as a separate git remote (I usually call this one "upstream" and my "fork", well, "fork"), fetch and pull from upstream, then push to fork.
shkkmo 2y ago
All you should have to do is just clone the repo locally and then create a blank GitHub repository, set it as the/a remote and push to it.
JyB 2y ago
That’s beside the point. The article is specifically about « GitHub forks » and their shortcomings. It’s unrelated to pushing to distinct repositories not magically ´linked’ by the GH « fork feature ».

ff7c11 2y ago

A fork of a private repo is private. When you make the original repo public, the fork is still a private repo, but the commits can now be accessed by hash.

CGamesPlay 2y ago
According to the screenshot in the documentation, though, new commits made to the fork will not be accessible by hash. So private feature branches in forks may be accessible via the upstream that was changed to public, if those branches existed at the time the upstream's visibility changed, but new feature branches made after that time won't be accessible.
- pcthrowaway 2y ago
  OK but say a company has a private, closed source internal tool, and they want to open-source some part of it. They fork it and start working on cleaning up the history to make it publishable. After some changes which include deleting sensitive information and proprietary code, and squashing all the history to one commit, they change the repo to public. According to this article, any commit on either repo which was made before the 2nd repo was made public, can still be accessed on the public repo.
  - reisse 2y ago
    > After some changes which include deleting sensitive information and proprietary code, and squashing all the history to one commit, they change the repo to public. I know this might look like a valid approach on the first glance but... it is stupid for anyone who knows how git or GitHub API works? Remote (GitHub's) reflog is not GC'd immediately, you can try to get commit hashes from events history via API, and then try to get commits from reflog.
    - marcosdumay 2y ago
      Yes, even though I expect there to be people that do exactly what the GP describes, if you know git it has severe "do not do that!" vibes. Do not squash your commits and make the repository public. Instead, make a new repository and add the code there.

rkagerer 2y ago

Am I the only one who finds this conceptually confusing?

rocqua 2y ago
Nope, me too. The whole Repo network thing is not User facing at all. It is an internal thing at GitHub to allow easier pull requests between repo's. But it isn't a concept git knows, and it doesn't affect GitHub users at all except for this one weird thing.
- brazzledazzle 2y ago
  I may be recalling incorrectly but I seem to remember it having some storage deduplication benefits on the backend.
- tedmiston 2y ago
  > Nope, me too. The whole Repo network thing is not User facing at all. There are some user-facing parts: You can find the fork network and some related bits under repo insights. (The UX is not great.) https://github.com/apache/airflow/forks?include=active&page=1&period=&sort_by=stargazer_counts https://github.com/apache/airflow/forks?include=active&page=...

itsgabriel 2y ago

Funnily enough the docs are wrong, the GitHub CLI allows changing a forks visibility https://stackoverflow.com/a/78094654/12846952 https://stackoverflow.com/a/78094654/12846952