That's a good question, and I don't immediately have the right answer. One answer that comes to mind is to remember this, and on the master branch revert the commit after the merge that introduces it.
X--o--A--o--o [v2.4_branch] \ \ o--o--o--M--A' [master] X represents the place where we branched 2.4, A represents the change to disable incomplete pncconf features, and A' represents the revert of A. (Optionally, squash A' into M so that they're a single commit) Another answer is to remember this, and do something special at the next merge: X--o--A--o--o [v2.4_branch] \ \ \ o--M1-M2--o [master] M1 is a merge done from the last commit before A. It is done like a normal merge. M2 is done immediately after M1 but uses the "ours" merge strategy, so that none of the changes introduced by A are in M2. I'll do a bit more googling because I'm sure there are other ways, and maybe there's a better one. Jeff ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers