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

[Benny Halevy]

On Feb. 12, 2008, 17:07 +0200, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 2008-02-11 at 21:53 -0800, Greg KH wrote:
>>> this is why you need specific trees for just the API change, and these
>>> need to EXPLICITLY go first before EVERYTHING ELSE. Yes this needs a
>>> bit of coordination, but it's the only way.
>> Even then, it will not work.
>>
>> Again, Roland isn't going to want to always pull in my driver tree just
>> to build his tree.  He wants to, and needs to do his own development
>> effort.
>>
>> But when we merge them together, there would be problems.
>>
>> So, you can't just "drop" the IB tree.
>> You can't just "drip" my tree.
>>
>> Where do you "fix this up" at?  I can send a patch for the IB tree, but
>> Roland can't put it in his tree, and I can't put it in my tree, it needs
>> to go _after_ both of our trees.
> 
> Actually, we had exactly this issue with the SCSI bidirectional patches:
> They depended on the sg_table patches in block.  The solution I adopted
> was two merge trees:  One to go in immediately with no dependencies
> (scsi-misc-2.6) and the other based on the pieces of block (so it would
> compile and apply) to go in mid way through the merge round after block
> (scsi-bidi-2.6).  What I did was keep rebasing the bidi tree until I
> could see there was nothing other than a plane base before merging it.

My take on this, in retrospect, is that the code should probably have been
developed in one branch off of one of the trees, or maybe even better in a
third tree.

The point is that the structure of git trees followed the organizational
structure rather than the problem at hand and if contributions coming
from different trees depend on each other, staging branches should be created
in the integration tree for working out the conflicts and when ready,
the integrated branches should be pushed towards the tree's trunk.

> 
> Of course, this only worked because Jens has a git tree ... it would
> have been a lot harder (but not impossible) if I'd had entangled patches
> from a quilt tree.
> 
> So I've already proven that the split tree solution is viable, if not
> pretty.  The bidi tree had to be rebased an awful lot as the block trees
> changed and rebased.  Unfortunately, git isn't very good at this, I
> eventually had to keep a base and a top reference and just try to cherry
> pick this series into the new constructed block tree.  But it can be
> done...


I developed git-rebase-tree (http://git.bhalevy.com/git/gitweb.cgi?p=git-tools.git;a=blob_plain;f=git-rebase-tree;hb=HEAD)
for exactly this reason - frequently rebasing sub-branches in the linux-pnfs tree
and my experience so far is that it really speeds things up for me and Boaz.
Please feel invited to try it out, I think it's very to close to be mature enough
for general availability (I know, I know, it'd be perfect if this functionality
would be merged into git-rebase :)

> 
>> That's what -mm has been able to handle so far, and that needs to also
>> work with -next.
> 
> Actually, we never successfully got block and bidi via -mm.
> 
> James
> 
> 

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