> 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.
You're misunderstanding the intent I think. This isn't a guarantee that the code is kept private. It's a guarantee that the other copies don't have a Github "fork" relationship to the true repo.
Nobody is disputing that access to the private repo allows for a copy to be kept. But it's an "island", not a fork.
> 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.
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.
While yes, you can simply create a new repo on GitHub with the local copy and name it similarly, it will not be linked to the original as a fork on GitHub.
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.