Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes: > Quoting "Raimund Berger" <raimund.berger@xxxxxxxxx>: > >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html