4 ms·

"This unfortunately makes sense because it is a private repo." I disagree. I expect a (i.e. my) fork to be independent of the original repository, no matter if

"This unfortunately makes sense because it is a private repo." I disagree. I expect a (i.e. my) fork to be independent of the original repository, no matter if it is private or not. It's enough if a fork of a private repository is private then too.

bcrosby95 4y ago
This is why I don't use github's fork feature. There's more than just this restriction they impose upon you. Instead I prefer to use a "git" fork. I just clone it and upload it to my own repo. Assuming the license permits of course.
- ntrz 4y ago
  Don't you need to have an "GitHub-approved" fork (i.e. use the GitHub fork button) if you want to create pull requests on the upstream project in GitHub? Or is there a way to do that from the kind of repo you're describing?
  - edaemon 4y ago
    If that came up you could create a GitHub-native fork and add that as a remote.
- dreamcompiler 4y ago
  This is the right answer: Break the fork link. I sometimes do this to make a private "fork" of a public repo so that I can add my own notes about how to use it, remind myself what happened when I tried it, add a config script for my own peculiar setup, etc. It's unfortunate because not having a "real" fork makes it harder to send pull requests and track the upstream. But it's sometimes necessary to get around stupid github policies.
naikrovek 4y ago
Don't use the "Fork" button in the GitHub UI, then. It is intended for collaboration and establishes and maintains the parent-child relationship of "your fork" and if the parent repo is deleted, so are all forks. If the parent repo is private and goes public, so do all forks. If the parent repo is public and switches to private, so do all forks. This behavior is laid out in docs.github.com and is not secret. This has been the case on github.com for over a decade, and I am slightly shocked that people don't know this. I guess the root of that is that I am surprised that this has not bitten more people than it has. People assuming things are a certain way and never checking to verify that are by far the greatest source of "I shot myself in the foot" statements that will ever be known.
- kitkat_new 4y ago
  "If the parent repo is private and goes public, so do all forks." nope, that's not true: "GitHub will detach private forks and turn them into a standalone private repository. For more information, see "What happens to forks when a repository is deleted or changes visibility?"" " If the parent repo is public and switches to private, so do all forks." This isn't true either: "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private." In these cases, exactly what I would have expected happens.
  - naikrovek 4y ago
    yep I was wrong about that point. generally my point still stands; if you want total control over your repo, don't use the GitHub "Fork" button to create your repo for that code. I linked directly to the documentation about "Fork" in another comment.
- mattigames 4y ago
  That would make sense if they didn't use the word "fork" for it, that words has a specific meaning when talking about repositiories[0] and it doesn't include a automatically propagating deletions or settings of the original repo, it doesn't actually include ANY automatic propagation, therefore GitHub should use a different word for this kind of fork, something like "Crate child fork" or "Linked fork" or maybe a new word altogether [0] http://www.freekb.net/Article?id=1263 http://www.freekb.net/Article?id=1263
  - djur 4y ago
    GitHub coined this particular use of "fork", and it's always been about having an automatically managed relationship between the original repository and the new one. A copy without that automated connection is a clone.
    - MereInterest 4y ago
      No, it definitely predates GitHub. And git itself, by at least a full decade. https://en.wikipedia.org/wiki/Fork_(software_development)#Etymology https://en.wikipedia.org/wiki/Fork_(software_development)#Et...

bcrosby95 4y ago

This is why I don't use github's fork feature. There's more than just this restriction they impose upon you. Instead I prefer to use a "git" fork. I just clone it and upload it to my own repo. Assuming the license permits of course.

ntrz 4y ago
Don't you need to have an "GitHub-approved" fork (i.e. use the GitHub fork button) if you want to create pull requests on the upstream project in GitHub? Or is there a way to do that from the kind of repo you're describing?
- edaemon 4y ago
  If that came up you could create a GitHub-native fork and add that as a remote.
dreamcompiler 4y ago
This is the right answer: Break the fork link. I sometimes do this to make a private "fork" of a public repo so that I can add my own notes about how to use it, remind myself what happened when I tried it, add a config script for my own peculiar setup, etc. It's unfortunate because not having a "real" fork makes it harder to send pull requests and track the upstream. But it's sometimes necessary to get around stupid github policies.

naikrovek 4y ago

Don't use the "Fork" button in the GitHub UI, then. It is intended for collaboration and establishes and maintains the parent-child relationship of "your fork" and if the parent repo is deleted, so are all forks. If the parent repo is private and goes public, so do all forks. If the parent repo is public and switches to private, so do all forks. This behavior is laid out in docs.github.com and is not secret. This has been the case on github.com for over a decade, and I am slightly shocked that people don't know this. I guess the root of that is that I am surprised that this has not bitten more people than it has. People assuming things are a certain way and never checking to verify that are by far the greatest source of "I shot myself in the foot" statements that will ever be known.

kitkat_new 4y ago
"If the parent repo is private and goes public, so do all forks." nope, that's not true: "GitHub will detach private forks and turn them into a standalone private repository. For more information, see "What happens to forks when a repository is deleted or changes visibility?"" " If the parent repo is public and switches to private, so do all forks." This isn't true either: "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private." In these cases, exactly what I would have expected happens.
- naikrovek 4y ago
  yep I was wrong about that point. generally my point still stands; if you want total control over your repo, don't use the GitHub "Fork" button to create your repo for that code. I linked directly to the documentation about "Fork" in another comment.
mattigames 4y ago
That would make sense if they didn't use the word "fork" for it, that words has a specific meaning when talking about repositiories[0] and it doesn't include a automatically propagating deletions or settings of the original repo, it doesn't actually include ANY automatic propagation, therefore GitHub should use a different word for this kind of fork, something like "Crate child fork" or "Linked fork" or maybe a new word altogether [0] http://www.freekb.net/Article?id=1263 http://www.freekb.net/Article?id=1263
- djur 4y ago
  GitHub coined this particular use of "fork", and it's always been about having an automatically managed relationship between the original repository and the new one. A copy without that automated connection is a clone.
  - MereInterest 4y ago
    No, it definitely predates GitHub. And git itself, by at least a full decade. https://en.wikipedia.org/wiki/Fork_(software_development)#Etymology https://en.wikipedia.org/wiki/Fork_(software_development)#Et...