Re: Premerging topics

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 24, 2013, 07:14 UTC
Message-ID: <7vppxkflhq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALKQrgd8jZQ__rnAT3wbfx-Y6mg-vrTdam53nS2ya2c=yMcS6Q@mail.gmail.com>

Johan Herland <johan@herland.net> writes:

Show 7 quoted lines

> This raises the same question I recently asked Antoine: For a given
> prepackaged merge <X,Y>, do we assume that it only resolves conflicts
> between the changes introduced in commit X vs. changes introduced in
> commit Y, or do we assume that it resolves conflicts between the
> histories leading up to X and Y, respectively? In other words, does
> <X,Y> _supercede_ earlier pre-merges between the histories leading up
> to X and Y?

That is an interesting question.  There are largely two cases.

When you replayed M---F to produce N---F', there may have been no textual or semantic conflict. Which means that there were no new reason between A--X and B--Y that necessitates an evil merge. A later merge between a descendant of X (but not Y) and a descendant of Y (but not X) can cherry pick the same <A,B> (M---F) on top of a mechanical merge,

On the other hand, you may have had either a textual or a semantic conflict when replaying <A,B> on N, and you had to fix up F' for it to be the correct resolution of merge between X and Y.

  ---o---o---A---o---X
      \               \
       \               N---F'
        \             /
         o---B---o---Y

In such a case, you do want to record the fixed N---F' as the prepackaged resolution for <X,Y>. Any time later when somebody is on a branch that has X (but not Y) and merges a branch that has Y (but not X), that N---F' should be the one to cherry-pick on top of a mechanical merge O between S and T. What <A,B> (M---F) did is superseded if you are going to replay <X,Y>.

  ---o---o---A---o---X----------S
      \       \       \          \
       \       M--F    N---F'     O---F''
        \     /       /          /
         o---B---o---Y----------T

You can tell that by noticing that A is an ancestor of X and B is an ancestor of Y. As you said, this is a good way to reduce the number of prepackaged evil merges that need to be considered.