On Tue, 1 May 2007, Jakub Narebski wrote: > > In "Producting Open Source Software" Karl Fogel gives an example of > GCC/EGCS fork, which resulted in "fast forward" merge (EGCS which was > fork of GCC, became next version of GCC). The egcs fork was a total disaster, and a big part of that was CVS and the tight control of the gcc tree. It took _years_ for people to get so fed up with the gcc maintenance that the egcs tree happened at all, and it was a prime example of how *painful* CVS makes this, and how it allowed the gcc maintainers to do a really bad job, and ignore a whole lot of major problems simply because the whole gcc setup was so hard to get into. So yes, the egcs fork is a great example. It was not only a required (and very good) fork, but it is _also_ an example of a setup where all the infrastructure made the fork take a lot longer to materialize and be a lot more painful than it should have been. > But for example GNU Emacs / XEmacs fork will never be merged, I think. > So not always you can merge a fork - you can try, unless codebase diverged > too much. In all honesty, I don't think any tools would help there. Git can make merging easier, but it cannot solve the fundamental differences in personality and it can't help with ten years of differences. Git tries to make merging easy by making it happen all the time, and thus the git merge capability really depend on changing the *model*. But git cannot really help you all that much if you have a decade of split, and the codebases just don't look similar any more.. (Not entirely true: git obviously does make merging easier, since people have piped up to say that they imported branches from SVN just to merge them in git and push the result back to SVN. So git _does_ help on the pure technical side too, but I think the even more important part is how git tries to encourage the model to be that one or both sides just merge often enough that the merges _stay_ easy). > What is or is not a fork is a bit blurry in the world of distributed > version control systems. Is a clone of repository a fork? I think that > everybody would agree that it is not. Is for example *-mm tree a fork? > I'd say not. But I'd say that Beryl is a fork of Compiz... Well, the -mm tree is a fork, but perhaps the difference is that the _intention_ is to merge back. We've had "real forks" in the kernel community too. Vendor branches for a while tended to be real forks - not because the vendors didn't want to merge back, but simply because they didn't have the capability and commitment to do so. That's changed, partly because 2.4->2.6 was so painful for some of them. And the VM people have had real forks. The -aa tree wasa real fork in the 2.4.x timeframe. So I think the reason kernel people don't really think about "-mm" as a fork is that we've tended to be pretty amicable about the forks, whatever the intention was. I personally encourage them, for example, in ways that most other bigger open source projects do not. That makes it easier psychologically to fork, but more importantly, it also makes it easier to join back again, because there was generally no hard feelings, just differences of opinion on technical matters that didn't get to be _too_ personal. So to _me_, the big issue is not so much forking, but joining it all back (ie merging). Forking should be trivial, and not even worthy of any real discussion. It should be a daily event, and sure, you'd expect the small forks to heavily outnumber the big ones, but none of that really matters if you just consider forking to not be a big deal - and always realize that joining back is where the interesting stuff happens! Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html