3 ms·

I still respectfully disagree. If GitHub really wanted to deceitfully name this feature to foster the cathedral model they would have gone with "branch" instea

by 3JPLW 7y ago

I still respectfully disagree. If GitHub really wanted to deceitfully name this feature to foster the cathedral model they would have gone with "branch" instead. In fact, I recall them getting quite a bit of push back for naming it "fork" because it has historically been a pejorative term. Even further, I believe the actual operation is implemented as a branch on their backend for efficiency's sake. So why go so far as to call it a fork? Well, because you can treat it as a fully maintained source tree itself (and participating like a member in a bazaar). It's easy to turn on issues locally, add collaborators, accept pull requests, and trade commits back and forth between the forks. Now, yes, GitHub does by default "link" it to the upstream repository and it even keeps tabs on how its history differs, but I'd call these features that reflect real use-cases. Also amusing is how the repositories on kernel.org describe themselves; 149 use the word "fork". Sure, it's probably partly due to how GitHub uses this terminology, but I'd say it's a good thing that forking is no longer pejorative by default — now it's a "hard fork" that's a bad thing.

usrusr 7y ago
Without github's "fork" branches we would most likely still see repositories initialized from plain source dumps popping up all over the place, just like in the days of nondistributed VCS. There is no technical reason to do that, but that is insufficient in presence of social reasons: Someone wants to exploratory tinker around, maybe scratch some personal itch. No problem, check out, go wild in the working copy. Pretty soon they want it backed up in the cloud, maybe transfer it to another machine. VCS to the rescue. But do you want to create a branch on the official repository? Hell no, definitely not ready for that. git veterans will casually add another remote (and even that won't be as good as a branch/"github fork"), but a lot of people would choose the devil they know, rm .git and reinitialize. Everybody loses. The forker loses history, easy merges from upstream and almost all chances of getting merged back into upstream. The project loses a potential committer and general overview of what is going on at the fringes. Github wastes traffic and storage and loses the moat that socially linking up forker and project would have been. Github "fork" strikes the perfect balance between proximity and distance: all the benefits of a branch, all the freedom of working in your own personal account. With this github have solved the problem of source dump repos so hard that we easily forget that it ever existed.
- johannes1234321 7y ago
  > Without github's "fork" branches we would most likely still see repositories initialized from plain source dumps I doubt that. Git inherently allows pushing and pulling from anywhere. You can easily create a new repo on GH and push your branch(es) from your local clone there. Creating a new clean repo is more work. See how Linux works.
hermanradtke 7y ago
You can email GitHub and have them remove the link to upstream after the fact too. I did this after I forked upstream to send a bunch of patches and then decided to take the project in a different direction as an experiment. Github has a bunch of issues, but the way they fork is not in my top 3.

by 3JPLW 7y ago

usrusr 7y ago

Without github's "fork" branches we would most likely still see repositories initialized from plain source dumps popping up all over the place, just like in the days of nondistributed VCS. There is no technical reason to do that, but that is insufficient in presence of social reasons: Someone wants to exploratory tinker around, maybe scratch some personal itch. No problem, check out, go wild in the working copy. Pretty soon they want it backed up in the cloud, maybe transfer it to another machine. VCS to the rescue. But do you want to create a branch on the official repository? Hell no, definitely not ready for that. git veterans will casually add another remote (and even that won't be as good as a branch/"github fork"), but a lot of people would choose the devil they know, rm .git and reinitialize. Everybody loses. The forker loses history, easy merges from upstream and almost all chances of getting merged back into upstream. The project loses a potential committer and general overview of what is going on at the fringes. Github wastes traffic and storage and loses the moat that socially linking up forker and project would have been. Github "fork" strikes the perfect balance between proximity and distance: all the benefits of a branch, all the freedom of working in your own personal account. With this github have solved the problem of source dump repos so hard that we easily forget that it ever existed.

johannes1234321 7y ago
> Without github's "fork" branches we would most likely still see repositories initialized from plain source dumps I doubt that. Git inherently allows pushing and pulling from anywhere. You can easily create a new repo on GH and push your branch(es) from your local clone there. Creating a new clean repo is more work. See how Linux works.

hermanradtke 7y ago

You can email GitHub and have them remove the link to upstream after the fact too. I did this after I forked upstream to send a bunch of patches and then decided to take the project in a different direction as an experiment. Github has a bunch of issues, but the way they fork is not in my top 3.