That makes no sense to me. You're relying on people not making their forks out of github. If that strategy works at all, it's incidental and I wouldn't rely on it for anything that matters.
I'm not. Did you read my 3rd paragraph?
This is not a security strategy, it is a strategy for managing relationships--which is the purpose of using Github in the first place. There are far more secure ways to manage a git repo than Github, if that is the goal.
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.
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).
Yup. So I'm not the only one seeing it then.
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.
> 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-...
in this context, those mean the same thing. if you copy the code it's not a "fork" in github terms.
that's not a github fork; and as they said, it's not really a 'security strategy' (mostly it's a bit of accounting).
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.
That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code."
No, he made two points. The first one is that this way you don't have your code in random freelancer's accounts, which I'm saying is wrong: a freelancer can take his code, and upload it back to his account.
So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts, you're mistaken too.
In fact if you don't believe me give me access to your private repos and lets see what happens.
Nobody is disputing that access to the private repo allows for a copy to be kept. But it's an "island", not a fork.
Come on, no one is arguing that, and I'm sure you know that.
He said it's "cleaner", not more secure. Yes anybody can re-upload his code to a random github account, but then it's easier to see it's stolen code in contrast of having a github fork of the private repository.
Nobody but you is claiming this.
> It means there are no abandoned copies of my codebase sitting around forever forgotten in random Github accounts.
Being legit doesn't seem to have any meaning for him or the author of the article. Also the code is the only thing needed for legitimacy. The iphone bootloader code in some repo is still the legit iphone bootloader (as an example)
It's really a false sense of control.
What if rockstar123 gets arrested for ICO fraud. Do you want others to see he has an official upstream link to your repo even after you have severed the relationship?
What if rockstar123 makes his fork public? It's just messy to keep the link.
out of curiosity, what made you think that?
> Why? Because it's cleaner. It means there are no abandoned copies of my codebase sitting around forever forgotten in random Github accounts. I set up a private repo because I want to control access to my code. That's why a private repo is private.
That's like me make a random repo and adding a readme that says "official public windows 10 source repo"
- collaborator get a copy of your code, works a bit on it;
- collaboration stops;
- a few months pass and you start collaborating with the same person again;
- collaborator then pushes some changes based on outdated information and breaks everything
github does have better ways to prevent that. that's the point of using git, right?