Re: Newbie question regarding 3way merge order.

Sitaram Chamarty <sitaramc@gmail.com> writes:

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.