Posted May 15, 2008 4:55 UTC (Thu) by dlang (✭ supporter ✭, #313)
Parent article: The Freedom of Fork
with distributed VCS systems the difference between a branch and a fork boils down to intent
about as much as any technical matters.
the distributed VCS systems also make it much easier to merge branches and forks togeather
(with git as the extreme case where there is no difference, and no technical distinction
between the 'original' and the 'fork')
with this in mind the GitHub 'fork' button isn't as nearly as bad as if the same thing was
being done with CVS or subversion.
Posted Aug 30, 2008 23:28 UTC (Sat) by Dieter_be (guest, #53677)
[Link]
Exactly.
Technically, a fork on github is actually a git clone.
People doing 'forks' on github will in 99% of the cases try to get their code merged in the mainline (issuing a 'pull request' of the fork). The other 0.9% just wants his own codebase to play with and also does not intend a real fork in the classic meaning.
So this is something totally different then forks in the classic terminology.
Also, git makes it easy to import changes after branches have diverged a lot, so that should promote the 'giving back to the original project/other forks' part.
Besides, I think that just because the barrier is so low, people who want to fork in the classic sense but without thinking things trough will abandon their fork pretty soon / won't achieve results that pulls users away anyway. Not a big loss for the broader public there... A fork can only be successful and get much adoption if it's well thought out and in that case we don't have much to fear.
just my 2c.