Hacker News Reader

Hacker News

Comment by kitkat_new | Hacker News Reader

Parent Full thread

kitkat_new

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

View on HN

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.

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.

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?

If that came up you could create a GitHub-native fork and add that as a remote.

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.

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

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.

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

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.

No, it definitely predates GitHub. And git itself, by at least a full decade.

https://en.wikipedia.org/wiki/Fork_(software_development)#Et...

GitHub specifically invented the idea of "forking" as a social action on a forge site that allows you to create your own associated copy of a repository. This is related to but different from the broader meaning of "fork". "Fork" doesn't mean anything at the git level.

I'm not sure exactly the distinction that you're trying to make. I see GitHub's use of "fork" as a specific application of the broader meaning of "fork", not an invention of a new and distinct concept. Just as putting "wheels" onto a steam engine can produce a new type of vehicle but doesn't change the concept of "wheels", GitHub's use of "fork" doesn't fundamentally change the broader concept of "fork".

If any changes done to the parent repository propagate automatically to "forked" repositories without the explicit consent of the _owner_ of the fork then it does change the broader concept of fork, and to follow your analogy it would be like calling a caterpillar track a wheel.

If this is acceptable because the original version it's a private repository that is unrelated, what we are discussing is the meaning of the word itself.

I think we are in agreement. Because access to the "forked" repository was removed without the consent of the owner of the fork, it is inaccurate for GitHub to describe it as a "fork". For clarity, I would also describe the "owner" of the fork as the person who created the fork.

I see the fork feature useful since for example if you fork a project that is no longer maintained user can search in the forks and find that you are now maintaining it. I've found myself doing it a lot of times.

Regarding forking a private repository with a public repository, it's a corner case for sure. In my opinion it's best to forbid forks of private repositories at all, and forbid to make a repository that has forks private, than to create problems like the one of the user in this topic.

Reply on news.ycombinator.com