131–140 of 294 posts
Earlier quoted context omitted.
so what? Private doesn't imply (common sense) that the original repository has power over any fork.
That is the exact meaning, which does seem to be common sense. You can fork from a public, private or internal repo. Public is public and the fork won't get deleted when the repo removes you. Private deletes your fork, since it isn't your repo. Internal requires gated access.
Earlier quoted context omitted.
That is the exact meaning, which does seem to be common sense. You can fork from a public, private or internal repo. Public is public and the fork won't get deleted when the repo removes you. Private deletes your fork, since it isn't your repo. Internal requires gated access.
for me the exact meaning for private is "available for a selected audience"
Earlier quoted context omitted.
You mentioned in another post that the company only released a cleaned up version publicly. That cleaned up code which they published is clearly and unambiguously under the MIT license. Any other modifications that were made and not published (including any you made in your fork as an employee) are not automatically licensed as MIT. Your employer holds the copyright to that. They might be fine with those internal cha…
If the private repo had the MIT license in it, then it was licensed with the MIT license, regardless of how widely or publicly the repo was distributed.
Once the organization publishes the software to others, whatever license documentation they include with it is binding, unless other issues trump that (like them not holding the copyright to begin with).
I'm not sure why people are defending Github on this issue, what if the original repo was a template or something, and your thousands of lines of code is gone because the original template repo removed you as a contributor. If I copy something, I expect where I copied it from to have exactly zero bearing on what happens to my copy. If they have a problem they can serve legal documents, giving everyone time to figure…
Earlier quoted context omitted.
Is the "main" branch an advantage? I guess only if >50 percent of your repos use "main" branch
[flagged]
We all know why this change exists, and why some people will attempt to persuade others of it's superiority. It is, however, just silly virtue signaling, and it's exhausting to hear and read.
It would require some very irrational and underdeveloped reasoning to assert this word has anything to do with oppression in 2023. There is no negative connotation, except in those who wish to perpetuate some weird sensation of altruism... ie. no one is safer or feels better simply because you choose to call it "main" rather than "master".
0. Or a homelab, or a cheap 256MB VM, or a NAS that can run docker containers, or an old Chromebook: anything that can execute a Go binary, x64, arm6 or even mips
Earlier quoted context omitted.
so what? Private doesn't imply (common sense) that the original repository has power over any fork.
It does, otherwise github just wouldn't allow forking private repositories. If they did allow that, and retained no control over the forked copy, now you can ride a coach and horses through the access control to a private repo by simply forking it when you have access. My guess is that forking a private repository is a feature github intended to be used where employees or contractors of an enterprise want to fork the…
Actually that's not really true, since your access to the original repository could still be revoked, and you are left with what you got.
Further, see sibling comment.
"My guess is that forking a private repository is a feature github intended to be used where employees or contractors of an enterprise want to fork their employer's repository as part of their development activities for that employer."
what you describe is "internal visibility"
https://docs.github.com/en/repositories/creating-and-managin...
Earlier quoted context omitted.
> It will only be deleted if the repo you fork from is a private repository This makes sense. Thank you for clarifying that important detail. It seems to be missing from the parts of the discussion I've read here.
No, it doesn't. It only makes sense until you stop and go "Wait, no, hold on a minute. Why would they delete the fork instead of simply severing the fork relation in their fork relations table?".
I'm not sure why people are defending Github on this issue, what if the original repo was a template or something, and your thousands of lines of code is gone because the original template repo removed you as a contributor. If I copy something, I expect where I copied it from to have exactly zero bearing on what happens to my copy. If they have a problem they can serve legal documents, giving everyone time to figure…
But at the same time - who doesn't have local copies of anything they care about? What are they thinking!?