[replying only because no one else did; caveat reader!] On 2009-01-29, Raimund Berger <raimund.berger@xxxxxxxxx> wrote: > 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'd say yes. Finding the common ancestor and then applying the differences from both sides are operations that do not appear to be order dependent. > If yes, a followup question would be if the merge machinery sitting > beneath rebase is exactly the same as that of a standard merge. The merge "machinery" can be explicitly chosen using the "-s" (strategy) option, but for the same chosen strategy, I think yes it would be the same for a merge as for a rebase. > 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). That appears to be a different question than the one you started with. Reversing A and B is one thing, applying a sequence of merges in a different order is quite something else. -- 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
