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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
