Hello, James. James Bottomley wrote: >> Ah... poor wording from me. I meant the one based on merging and >> monotonic commit accumulation without rebasing. > > But that's not really possible here ... the only way to combine the two > incompatible trees now while maintaining bisectability is to hide a non > trivial patch in the merge point ... that's the worst practice of all. With proper commit message, I don't think straight merge would be that bad. The amount of conflicting code isn't that large. But we're talking about two extremes here. Straight merging at one end and keeping temporary tree till the merge into Linus's tree happens. The problem with floating the block tree till the final merge is that it might make SCSI happy but SCSI isn't the only consumer. It just doesn't scale. I don't really care about the specific merge order as long as there can be a mid synchronization point from which everyone can go on again and there are three trees involved and if there's any way to get a stable merge point from SCSI, things will work nicely. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
