Re: Newbie question regarding 3way merge order.

[Junio C Hamano <gitster@pobox.com>]

Sitaram Chamarty <sitaramc@gmail.com> writes:

> Reversing A and B is one thing, applying a sequence of
> merges in a different order is quite something else.

This point is true in theory but I haven't found it to cause problems in
practice.  Textual conflicts between topics do happen, but it does not
happen so often in overlapping areas across more than two topics that
earlier resolutions to them cannot be reused by the rerere mechanism.

Semantic conflicts and dependencies are harder to deal with.

Suppose you have a topic to introduce feature A.  You propose an
enhancement, validate what it does logically makes sense, queue it to the
testing integration branch and unleash it to the world for real world
testing.

    ---o-------*     test integration branch
      /       /
     /       o       feature A
    /       /
   o---o---o---o---o mainline

Later, you find out that there is a bug B, and your enhancement to
implement A does not work as intended when B triggers.

You could do two things.

 (1) You extend feature A topic and queue the fix there.

    ---o-------*---*  test integration branch
      /       /   /
     /       o---o    feature A + bugfix B
    /       /
   o---o---o---o---o  mainline

 (2) Because B is an independent bug, you can have its own topic to fix it
     and merge ot to test integration, planning to merge it later to
     mainline independently from feature A topic.

      ---o-------*---*   test integration branch
        /       /   / 
       /       /   o     bugfix B
      /       /   /
     /       o   /       feature A
    /       /   /
   o---o---o---o---o     mainline


Neither is satisfactory.

The former is bad because it takes hostage of a useful bugfix to the
feature.  Without adding the feature A, which may or may not be what
people want to have, you cannot merge the fix to the mainline.

The latter is better because bugfix B could independently be merged to
mainline, but it risks you forgetting to merge it when you merge feature A
to the mainline.  By the time you decide to merge feature A to the
mainline, the test integration branch has had both for some time, and you
didn't seen the problem bug B causes to feature A there, but if you merge
only feature A but not fix B to the mainline, suddenly you have a buggy
feature on the mainline.

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

This way, even if you later choose to merge feature A, forgetting that you
have to have bugfix B for it to work, to the mainline, the merge will
bring in the necessary fix with it automatically.

      ---o-------*---*   test integration branch
        /       /   / 
       /       /   o     bugfix B
      /       /   / \
     /       o-------*   feature A
    /       /   /     \
   o---o---o---o---o---* mainline

This technique to resolve conflicts and dependencies early between topics
to force a merge order to the mainline can be used not only to deal with
semantic conflicts but textual ones, too.  If two branches textually
interact badly, you prepare a consolidated topic between the two, so that
you can merge A alone, B alone, or A+B together to the mainline.

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.