Sitaram Chamarty <sitaramc@xxxxxxxxx> writes: > [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. That's exactly the point which I'd like to have clarified. E.g. with A, B and ancestor C, the merging and conflict resolution algorithm had to be completely symmetric if diff(A,C)+diff(B,C) applied to C should always be the same as diff(B,C)+diff(A,C) applied to C. So I'm really asking if that is a fact upon which I can rely. > >> 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. An interesting hint. Up to now, I assumed that rebase would always perform implicit merging strategies. I mean what else would one expect in the above picture to happen when rebasing A on B? I'd assume it'd produce the same tree as a merge of A into B, by employing exactly the same machinery. E.g. fast forward of C to B, then merge A in. So that, effectively, the only difference between rebase and merge is just commit history but not (tree) content. >From reading the rebase man page though it seems that merging machinery has to be explicitly requested via '-m'. Which makes me wonder how the default rebase actually works. > >> 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. Mathematically speaking, if A1 and A2 commute with regard to a binary operation, A1 ... An do as well. So I'd still think the latter question boils down to the commutativity question above *iff* rebase actually does an implicit merge by default. Which I'm now led to question. Thanks for you answer, much appreciated. -- 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
