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

[Junio C Hamano <gitster@pobox.com>]

Thomas Rast <trast@student.ethz.ch> writes:

> Stephen R. van den Berg wrote:
>> Junio C Hamano wrote:
>> >             o---...o---B---A
>> >            /                \ (wrong)
>> >        ---o---o---...o---X---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.
>> 
>> Which existing git command actually misbehaves because it makes the
>> above assumption?
>
> Most importantly: merge.

Yes, and this is not about "misbhave" and "assumption".  It is much more
fundamental.

Stephen earlier seems to have mistaken what I taught in an earlier message:

  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.

as a mere convention or something, but it is not.  It is what the merge
semantics and merge-base computation (implemented in mathematical terms
over commit DAG) do, expressed in layman's terms.

The decision to merge your history with A' means that (1) you trust what
you have done so far, (2) you trust the judgement of what the other person
who built the history that leads to A' as well, and (3) you deem that the
purpose of these two histories are compatible with each other.  The last
item is why you are merging with him.

                             v you were here
                     o---o---o---M
                    /           /
            o---...O---B---A   /
           /                \ /
       ---o---o---...o---X---A'

Because of the "I have considered all things behind this commit, and I
declare this tree suits my purpose better than any of them" statement when
a merge A' was made, and the fact that you trust the judgement of the
person who made that statement, and the fact that you think the purpose of
his history is compatible with yours, we look at O as the merge base when
merging with A' to create M, and resulting history that lead to M claims
that it has A _and B_, in addition to X and other developments done on the
bottom branch of his, on top of what you used to have.

However, the transition from A to A' involves reverting B among other
things, and the history M includes that revert.  That's the consequence of
you trusting judgement made when A' was made (i.e. "fix in B does not
matter, and reverting it is better for my history") and thinking that
judgement is compatible with the purpose of your history (i.e. "yes, I
agree that dropping the fix made in B does not matter to my history
either, and that is why I am merging with A'").