News for hackers. Stuff that matters.
Re:What is a fork, and how GitHub changed its meaning by usrusr on Friday May 24, 2019 @05:34PM (#20005480)
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.

Re:What is a fork, and how GitHub changed its meaning by johannes1234321 on Friday May 24, 2019 @07:20PM (#20006126)
> 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.