From: Junio C Hamano Date: Wed, 24 Apr 2013 07:14:57 GMT Subject: Re: Premerging topics Message-ID: <7vppxkflhq.fsf@alter.siamese.dyndns.org> In-Reply-To: Johan Herland writes: > This raises the same question I recently asked Antoine: For a given > prepackaged merge , 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 > _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 (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 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 . 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 (M---F) did is superseded if you are going to replay . ---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.