Re: Newbie question regarding 3way merge order.

["Raimund Berger" <raimund.berger@gmail.com>]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Quoting "Raimund Berger" <raimund.berger@gmail.com>:
>
>> The question is whether a (3way) merge is commutative, purely in terms
>> of content (i.e. disregarding commit history for now). Iow if no matter
>> in which order I merge A and B, i.e. A into B or B into A, I'd be
>> guaranteed to arrive at the same content.
>
> I think three-way merge of A into B and B into A will produce the same
> result when the merge doesn't conflict (when it does, you will get the
> conflict markers and text from A and B in a different order depending on
> the direction of the merge).
>
>> The reason I ask is obvious I guess. What basically interests me is if I
>> gave a bunch of topic branches exposure on a test branch and, after
>> resolving issues, applied them to stable, that I could be 100% sure to
>> not introduce new issues content wise just by applying merges in a
>> different order or form (rebase, patch set).
>
> I don't think you can make a blanket conclusion like that by only knowing
> that merging A into B and merging B into A would produce the same result.
>
> If you merge topics A, B, and C in this order into your current state O,
> there may not be any conflict, but if you merge the same topics to the
> same current state in different order, C, B and then A for example, you
> may get conflicts that breaks the merge. The commutativeness only says
> that merge of A into O will produce the same result as merge of O into A.
> It doesn't say anything about what would happen when you merge B to O.

That's correct. Strictly speaking one would also have to verify
associativity. I.e. whether merge(merge(A,B),C) == merge(A,merge(B,C))
for all A,B,C.

Thanks for making an implicit point explicit. So a followup question
would be: is git's 3way merge associative?

>From my pov people seem to assume it.