On Tue, 12 Feb 2008, James Bottomley wrote: > > On Tue, 2008-02-12 at 09:09 -0800, Linus Torvalds wrote: > > (a) create a base tree with _just_ that fundamental infrastructure change, > > and make sure that base branch is so obviously good that there is no > > question about merging it. > > The problem is how do we use a? Usually we need to track your -rc tree > as our fixes go in ... some of which affect our development trees. So? > If we stick with (a) as the base, we don't get to pull in the fixes in > your tree. If we use your tree we have to pull in (a) creating n > different merge points for the n different upstream trees.. I don't understand what you mean. This is true whether you pulled (a) or not. If you have any changes what-so-ever in your tree, if you pull in fixes from my tree, you'll get a merge. But if you mean that you cannot rebase (a), then yes. That was what I said. Rebases *do*not*work* (and fundamentally cannot work) in a distributed environment. But why would you merge with my tree in the first place? My tree won't normally have any conflicts or anything like that anyway. With a "Linux-next" tree, you'll see the conflicts if they occur (since *that* tree would merge!), and in that case you would say "now I need to merge Linus' tree just to resolve the conflicts!" But before that, merging my tree (or rebasing on top of it) is simply *wrong*. It has nothing to do with your SCSI development. > Yes, this is effectively what I did with the post merge SCSI tree. > However, if you do this rebasing becomes a fact of life because you need > to rebase out all the dependencies you have before you merge (in fact, > it's a good way of checking whether your dependencies have been merged > yet or not, seeing what survives a rebase). I don't see the logic. You shouldn't need to rebase at all. I don't see why you claim that this makes rebasing more of a fact. It doesn't. It has no impact at all, except making rebasing _less_ possible! Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
