Date:	Tue, 12 Feb 2008 12:24:42 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeff Garzik <jeff@...zik.org>, David Miller <davem@...emloft.net>,
	arjan@...radead.org, greg@...ah.com, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

On Tue, 2008-02-12 at 10:00 -0800, Linus Torvalds wrote:
> 
> 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.

Yes, that's what I meant ... no rebasing of (a) once it becomes the
fixed point we all work from.

>  Rebases *do*not*work* (and fundamentally cannot work) in a 
> distributed environment.

Hm ... I think net is a counter example to this.  Rebases certainly work
for them.  The issue, I thought, was around the policy of rebasing and
how often.

I see the question as being one of who creates the history.  When
something goes into your tree, that's an obvious history point and we
can't rewrite it.  However, when something goes into my trees, I don't
think it's as obviously a history point that has to be preserved, so I
can rebase obviously, rebasing causes disruption, so I don't do it
unless it's necessitated by an actual conflict.

> 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.

This normally happens when we have bug fixes to a driver that is
simultaneously being worked on for the merge window ... and it actually
happens quite a lot.  Sometimes the conflicts actually don't come via my
tree (usually a -mm docbook update, include file removal or something
else that looked trivial to the submitter).

The worst examples of this are the "run lindent on the driver" type of
patches, but a lot of other changes give trivial conflict too.

> 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!"

Right ... that's exactly why I created the -mc tree ... it warns me that
there's a looming problem I need to fix (and not just in your tree).
For that reason, a -next tree that does exactly the same thing will be
great ... I won't have to maintain the -mc tree.

> 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 ... I don't do that ... Like I said, I only rebase for an actual
conflict.

> > 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!

Well, it came at me because Jens was rebasing the block tree as he
worked through issues in the two branches I was based on.  If the block
tree hadn't rebased, I wouldn't have rebased that often.  However, we
did come across other things that had to move from my tree to Jens' as
we developed this, mainly bug fixes moving closer to the source to
preserve bisectability, and in that case rebases were really necessary.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists