Re: Newbie question regarding 3way merge order.

Nanako Shiraishi [off-list ref] writes:

Quoting "Raimund Berger" [off-list ref]:

quoted

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).

quoted

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.