Re: Newbie question regarding 3way merge order.

From: Raimund Berger <raimund.berger@gmail.com>
Date: Feb 2, 2009, 14:58 UTC
Message-ID: <871vugc2c8.fsf@gigli.quasi.internal>
In-Reply-To: <7vskmyt127.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

[snip]

Show 17 quoted lines

> This is where you need to use the tool right to get the most out of it.
>
> You could do this in addition to (2).
>
>  (3) Because B is an independent bug, you can have its own topic to fix it
>      and merge it to the test integration, planning to merge it later to
>      mainline independently from feature A topic.  But you already know
>      feature A depends on bugfix B to work correctly, so you merge the fix
>      to the feature as well in advance.
>
>       ---o-------*---*   test integration branch
>         /       /   / 
>        /       /   o     bugfix B
>       /       /   / \
>      /       o-------*   feature A
>     /       /   /
>    o---o---o---o---o     mainline

You seem to suggest that juggling merges is possible in the exact way I was inquiring about. So let me ask again:

if M1 and M2 are merges and I define equality of merges (M1==M2) to be

- M1 resolves automatically (on the textual level) iff (if and only if)
  M2 does
- if either resolves automatically, the tree produced by M1 is the same
  as that of M2 (the tree SHAs are the same)

do the following conditions hold

(i) A+B == B+A for all commits A,B (ii) (A+B)+C == A+(B+C) for all A,B,C

where "+" designates the standard git 3way merge?

[snip]

> If you end up merging A first and then want to merge B later (or the other
> way around, merge B and then A), and if the second merge to the mainline
> causes huge textual conflicts, you can instead merge the conslidated topic
> A+B to the mainline.

One could imagine (corporate) policies though which might try to map organizational "entities" (tasks, teams, according responsibilities) to branches. I.e. contexts where conflict resolution through merging might not always be desired and they'd rather be sought on a branch, i.e. by producing a commit on either branch which resolves a possible conflict. That's why I asked how rebase compares to merge and whether the merge machinery underlying the former is exactly the same. I seem to understand by now though that it is not.