Re: Premerging topics

[Antoine Pelisse <apelisse@gmail.com>]

Should we think about adding some commands for that ?

On the very top of my head (there is certainly more than that):
- Save such a change: By basically creating a ref to HEAD (HEAD being
the commit, HEAD^ the fixed merge) with merge-fix/HEAD^^1-HEAD^^2
- Apply the merge-fix: On top of a merge, find the most recent
merge-fix for HEAD^1/HEAD^2 (according to what was discussed), and
squash it.

On Wed, Apr 24, 2013 at 9:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johan Herland <johan@herland.net> writes:
>
>> 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.
>