Hello, James. James Bottomley wrote: > No ... postmerge trees are held by maintainers for irreconcilable tree > conflicts. You run your standard tree, which can fire at any time in > the merge window and your postmerge one which pulls in the entangled > tree and adds your patches on top. This can only go after the > conflicting subsystem has also been pulled into linus head. > >> Out of curiousity, is there any reason not to use more standard git >> workflow? > > This is a standard workflow ... Ah... poor wording from me. I meant the one based on merging and monotonic commit accumulation without rebasing. > it's how we've pretty much always sorted out entanglements ... at > least it's between me and Jens, which are two git trees ... I've had > to run post merge trees against gregkh's quilt before now. > >> Developers (kernel devs at least) are now pretty comfortable with >> git and trees merging and splitting off. I can't really see much >> value in rebasing these days. > > That depends. It's not unusual for patches to get dropped or moved > around in my trees (I try not to do it often) which can't be done > without rebasing. That pretty much precludes merging because I need a > cleanly rebaseable change set. The only benefit I can see for rebasing these days is cosmetic cleanup of commit history. Well, fixing history could help bisection at times but still I don't think it's anything substantial. Anyways, it's your tree and your call. Jens, how do you wanna proceed here? And is there anything I can do to help? 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
