Re: Announce: Linux-next (Or Andrew's dream :-))

[David Miller]

From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 12 Feb 2008 12:24:42 -0600

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

And I realize that regrettably I end up rebasing a lot.

Let's say that today I merge a TCP bug fix into Linus's 2.6.24-rcX
tree.  When I have the net-2.6.25 tree going I know that this is going
to create merge conflicts with the 80 or so odd TCP patches I have in
there.

Nobody can pull net-2.6.25 into Linus upstream without having to sift
through the merging of that stuff.  It never merges cleanly using
the automated mechanisms, because since the changes are split up
nicely there are long changeset dependency chains.

So I rebase, and do the merging work by hand.

Next, let's say Jeff merges some net driver bug fixes into upstream,
resulting in potential conflicts with the several hundred or so driver
changes that are in the net-2.6.25 tree too.

In fact near the end of 2.6.24 development, there was a new merge
conflict created on a daily basis with the net-2.6.25 tree.  You
simply cannot avoid this when you're managing 1500+ changes.

I even had to rebase the net-2.6.25 tree once or twice in Australia as
the merge window was openning up because I could push something
cleanly to Linus.  There were conflicts created by stuff that got in
before the net-2.6.25 tree, mostly in files like the feature removal
schedule, Kconfig files, and whatnot.

At times I even felt the urge to avoid merging a bug fix upstream
because of all the merge conflicts it would create, but I of course
can't and won't do that. 8)

It actually turns out that things simplify once a tree gets into the
-stable folks hands.  I pick out bug fixes as they go upstream, and
toss it to them once Linus sucks it in and I have an upstream
changeset ID to give them.  I don't have to worry about -stable
changesets causing development merge grief later on.

And I've also yet to be shown how to completely remove a changeset
from a GIT tree without rebasing :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/