Re: Newbie question regarding 3way merge order.

Junio C Hamano [off-list ref] writes:

[snip]

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.

Please don't set Mail-Followup-To: here, and keep the Cc: list.

Raimund Berger schrieb:

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?

I don't think that (ii) does holds in general.

[ In the examples consider each letter/symbol on a line by itself; this
saves vertical space. ]

Start with this (the merge base):

	f(a)

and there are three topic branches growing from here:
A makes this (rename f->g):

	g(a)

B makes this (add another f):

	f(a)f(b)

C makes this (renames a->c):

	f(c)

Then A+B is

	g(a)f(b)

A+C is

	g(c)

B+C is

	f(c)f(b)

(A+B)+C is

	g(c)f(b)

but A+(B+C) is ambiguous:

	g(c)f(b)
or
	f(c)g(b)

-- Hannes