You are viewing gitster

February 1st, 2009


Previous Entry Add to Memories Share Next Entry
10:40 am - Resolving conflicts/dependencies between topic branches early
When you use multiple topic branches, you integrate them into your test integration branch to make sure that they play well together. And by the time some of them prove to be useful and trouble-free, you merge the ones you like to the mainline, while keeping others still cooking in your test integration branch.

At least, that is the theory. And it works rather well in practice, if you do it right by separating logically independent ones into different topics.

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 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 it to the 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 see 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.
      ---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.


 





Tags:

(2 comments | Leave a comment)

Comments:


From:Jakub Narębski [openid.pl]
Date:February 2nd, 2009 10:26 am (UTC)

git-rerere

(Link)
How does git-rerere fit in this situation?
[User Picture]
From:gitster
Date:February 3rd, 2009 02:26 am (UTC)

Re: git-rerere

(Link)
If you had a conflict to resolve when you merged B to the test integration branch, you may have the same conflict when B graduates to the mainline. The resolution you made when you merged to the test integration will be remembered and reused by rerere when you merge to the mainline.
gitster's journal - Resolving conflicts/dependencies between topic branches early

> Recent Entries
> Archive
> Friends
> Profile

Links
Pages at the k.org
Gifts
貢ぎ物
The latest blog by Gitster

> Go to Top
LiveJournal.com