Hacker News Reader

Comment by gkya | Hacker News Reader

> it is a strategy for managing relationships

Not really. That means that you've worked with benevolent actors up until now. It's not that hard to keep a clone of the repo and upload later after the termination of the business rapport, either as a private or a public one.

View on HN

The people who have access to my private repos may or may not be benevolent, but they are certainly under contract, and that's the relationship that Github is helping me manage.

The contract says that the codebase is mine, and the contractor doesn't have rights to use it for their own purpose. The Github private repo rules just make that real in a practical sense. It means the default way of working comports with what the contract says. It makes it easy for everyone to do the right thing, and harder to do the wrong thing.

Sure, a rogue contractor could re-upload my codebase to a new repo in their account later, but that is a pretty obvious violation of the contract. If I found out, I'd feel pretty confident suing them (if it came to that). There's nothing they can point to that says I authorized them to do that.

In contrast, if the default was to leave an official fork of my code in their Github account forever, then it becomes easier for them to do the wrong thing, and harder for me to say I didn't want them to do it. Some future employee could even do the wrong thing accidentally.

To reiterate, Github private repos help me manage my relationships. They don't enforce the terms of my relationships.

You know how git work right? It is decentralised! I don't see any added value! When I work on a project I always have the master, develop and feature branche(s) pulled from the repo on my machine. I could just create a new private repo or even a public one and push my local branches.

But unless you are giving your contractors a locked-down internet-disconnected laptop and physically locking them in an empty room, you need to trust that they aren't going to steal your code like that anyway.

Certainly. I---and some others, seemingly---was just saying that what Github does is not that much of an help (which is what seems to be meant at the thread root). The keyword is contractor here, as it should be the contract that protects you from theft &c. Though I'm not much knowledgeable about business, so maybe I'm failing to see how that's useful.

> It's not that hard to keep a clone of the repo and upload later after the termination of the business rapport, either as a private or a public one.

that's not a github fork; and as they said, it's not really a 'security strategy' (mostly it's a bit of accounting).

Sure, but it won't say "forked from" on it.

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

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

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

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.

Reply on news.ycombinator.com