Re: Newbie question regarding 3way merge order.

From: Raimund Berger <raimund.berger@gmail.com>
Date: Jan 30, 2009, 19:09 UTC
Message-ID: <87vdrwbofv.fsf@gigli.quasi.internal>
In-Reply-To: <slrngo6eat.s1d.sitaramc@sitaramc.homelinux.net>

Sitaram Chamarty <sitaramc@gmail.com> writes:

Show 12 quoted lines

> [replying only because no one else did; caveat reader!]
>
> On 2009-01-29, Raimund Berger <raimund.berger@gmail.com> 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.

Show 7 quoted lines

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

Show 12 quoted lines

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