Hacker News Reader

Comment by wgjordan | Hacker News Reader

Shifting goalposts here- thread-parent said "I want their fork of my code to go away too," not "I want their fork of my code to no longer say 'forked from' on it".

If removing the relationship tag was the only purpose of this, GitHub could just remove the relationship tag, not delete the whole repository (throwing out the baby with the bathwater).

View on HN

This doesn't look like shifting goalposts to me — it looks like you misunderstood where the goalposts were to begin with. Read the original comment charitably rather than with an eye for holes and I think you'll see that it wasn't about persistent malicious actors, just about what they see as sane defaults for people's relationship with your codebase. Once you're no longer associated with their private codebase, they think it makes sense for you to no longer have an official copy of it in your Github account.

This is what I meant, in fewer words. Thanks.

> Shifting goalposts here- thread-parent said "I want their fork of my code to go away too," not "I want their fork of my code to no longer say 'forked from' on it".

in this context, those mean the same thing. if you copy the code it's not a "fork" in github terms.

> Shifting goalposts

Yup. So I'm not the only one seeing it then.

This is not what people expect, so that's one obvious reason it's very likely the wrong decision. I would have never known this. If you are relying on a public external product on github, you have to go several painful steps to make it 'safe', you have to re-upload it, and there's no good reason to make people do it. It's a giant disincentive to fork things on github. To be safe of finding things later, there will probably be another git repo website that will agree to "host" your forked projects safely, so that you can access them.

I understand on the other side, there's value in being able to stop people who forked your code. But it's a very weak stop-ability, because they could just keep the code locally and re-upload.

What does this have to do with public projects? This is entirely about private repos.

My understanding from reading that was that even on a "public" project the owner can delete it, change it's status, and it disappears from availability.

Fortunately not. As noted in the article[1] linked in the OP:

> Deleting a public repository

> When you delete a public repository, one of the existing public forks is chosen to be the new parent repository. All other repositories are forked off of this new parent and subsequent pull requests go to this new parent.

> Changing a public repository to a private repository

> If a public repository is made private, its public forks are split off into a new network. As with deleting a public repository, one of the existing public forks is chosen to be the new parent repository and all other repositories are forked off of this new parent. Subsequent pull requests go to this new parent.

[1]: https://help.github.com/articles/what-happens-to-forks-when-...

Thanks for the update. I can't add a post-comment to my question because it's been to long, but I was wrong.

Reply on news.ycombinator.com