On Tue, May 01, 2007 at 11:35:54AM +0200, Johannes Schindelin wrote: > > [...] > > > > Because a fork is bad for everyone (for reasons examined in detail in > > the section called "Forks" in Chapter 8, Managing Volunteers, > > http://producingoss.com/producingoss.html#forks), the more serious the > > threat of a fork becomes, the more willing people are to compromise to > > avoid it. > > This is a lousy argument, IMHO. > > Why are forks bad? They are not. But if you "learnt" that merges are hard, > they are. > > It is a pity that so many people were trained in CVS, and keep thinking > some of the lectures were true, when they are no longer. > > Forks are good. In fact, we all "forked" with CVS as soon as we began > hacking. Everybody who claims to never have started over from a fresh > checkout, or from an "update -C"ed state, is probably lying, or a bad > developer. Thinking about it, I believe that the difference between > forking and branching is philosophical, not technical. You can always > merge a fork. There's a confusion going on here between a "fork" meaning a branch in the SCM sense of the word, and a "Project Fork" where there are two camps competing for developers and users. So for example, having kerenl developers develop using branches which are then merged into the -mm tree and then into Linus tree --- Good. In the suspend-to-disk world, where we have *three* separate implementations, with two in the mainline tree, and one very popular one, suspend2, with features that niether of the in-mainline implementations have, and with Pavel constantly casting aspersions at Nigel because he's splitting the development effort --- Not So Good. I prefer to use the term "branch" to talk about a SCM and development series, and to use the term "fork" to talk about the political/project issues. So for example, even though Ingo Molnar's CONFIG_PREEMPT_RT patchset has been a very long-running thing, it is constantly getting rebased against the kernel, and there is no expectation that this would replace the mainline kernel. That makes a code branch, and not a fork. So my suggestion is to let branches be branches, and to reserve fork for when there is an attempt to compete for developer and user attention. That is more or less the general understanding of the two terms, and trying to confuse the two only leads to confusion and a general muddying of the waters. Regards, - Ted - 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