On Tue, 2008-02-12 at 17:32 +0200, Benny Halevy wrote: > 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. For your development, possibly, but not for my merge ... there were a lot of other patches besides yours in the bidi tree (it was, in fact, misnamed, but I thought at the time I created it it would only contain the bidi patches). > 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. Actually, I think you'll find the problem is that we can't build an integration tree that's both stable and long lived, and hence you can't base anything off it that requires a long lived base. So, the way I worked for your patches was to use the -mc tree to identify my conflicts, and only include the actual conflicting branches as a basis for the scsi-bidi tree beofre fixing up the patches. I then actually used the -mc tree as a canary to tell me when to rebase. James - 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