Re: [RFC] cherry-pick using multiple parents to implement -x

"Stephen R. van den Berg" <srb@cuci.nl> writes:

In general, I do not think what you did is a good idea. The _only_ case you can do what you did and keep your sanity is if you cherry-picked every single commit that matters from one branch to the other.

If something is not "parent", you shouldn't be recording it as such.

Remember, when you are making a commit on top of one or more parents, you are making this statement:

 * I have considered all histories leading to these parent commits, and
   based on that I decided that the tree I am recording as a child of
   these parents suits the purpose of my branch better than any of them.

This applies to one-parent case as well.

Imagine you have two histories, forked long time ago, and have side-port of one commit:

             o---...o---B---A
            /
        ---o---o---...o---X---A'

What side-porting A from the top history to create A' in the bottom history means is that the change between B and A in the top history, and no other change from the top history, is applied on top of X to produce state A' in the bottom history. What B did is not included in the bottom history.

If you recorded A' with parents A and X.  Here is what you would get:

             o---...o---B---A
            /                \ (wrong)
        ---o---o---...o---X---A'

But that is not what you did. The tree state A' lacks what B did, which could be a critical security fix, and you didn't consider all history that leads to A when you cherry-picked it to create A'.

To put it another way, having the parent link from A' to A is a statement that A' is a superset of A. Because A contains B, you are claiming A' also contains B, which is not the case in your cherry-picked history.