Re: Newbie question regarding 3way merge order.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> 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.

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux