Re: [Gnu-arch-users] Star merging with 3 branches

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

The very short answer:

You were merging in changes that are redundent.   By default,
those are marked as conflicts.   You can override that behavior
with:

        --forward

for _any_ merge operator, or (while also changing the way conflicts
get marked):

        --three-way

for star-merge.

If you can, retry the merge with one of those options and see if you
get less puzzling results.



The longer answer:

    > Here's our current tree:
    > 
    > mainline
    >    |
    >    +-release
    >        |
    >        smallfeatures

    > First, went into mainline and did star-merge project--release--version. 
    > Then I made CVS bring everything in mainline up to date.  Then I
    > committed with tla.

    > So now, mainline should appear to be all of release, plus other
    > changes.  Now there are changes in smallfeatures that I'd like to import
    > into mainline.  So I do star-merge
    > project--smallfeatures--version--patch-2.  And tla attempts to redo a
    > bunch of the changes that are already present in both the release and
    > mainline branches.  These changes don't have anything to do with
    > smallfeatures--version--patch-2.  Smallfeatures inherited these changes
    > from release.


star-merge is very cool and powerful, but it isn't magic.

Magic would be required for arch to "subtract out" in a perfect way
the changes from `release' that have already been merged into
mainline.  (We can talk about why, if you like, but I'll skip it
here.)

Instead of attempting magic, arch does something that is at least
predictable and that _approximates_ the magic -- it gives you the
option to _not_ treat as conflicts changes that appear to have already
been installed.   --forward and --three-way provide that option.

The "magic" that is required to subtract out redundent changes _can_
be performed (for real, without actual magic) in limited cases.   One
of those cases is when patch flow is along a "hub and spokes" (aka
"star") topology.


So, if you had:

        smallfeatures <--> mainline <--> release

that's a tiny "hub and spokes" with `mainline' as the hub (where the
arrows show what gets merged back and forth).

You could star-merge back and forth between mainline and the other two
branches without ever needing --forward or --three-way.   That "star
topology" property is why star-merge is called star merge.

In fact, you could have a more complicated graph of branches like:



                3          3
                 \        /
               3--2      2---3
                   \    /
                     1
                   /   \
               3--2     2--3
                  /      \
                 3         3


In that graph, where every node/number is a branch, you could
star-merge with impunity between any two directly connected nodes and
never need --forward or --three-way;  never have to worry about
redundent mergess.   Systems that don't keep track of and use merge
history don't provide that capability.   Topologies like that are, 
for example, how the linux kernel project works.

But `star-merge' can also be useful in other circumstances -- hence
its support for --forward.



    > I tried starmerging smallfeatures--version--patch2 into release, and
    > this works as I expected--no changes after the first .  

Right.   A strictly star-topology use of star-merge would have you
merging from small-features into release, and then from release into
mainlnie (like following a 3 <-> 2 <-> 1 path in the graph above).


    > But it seems impossible to convince arch that the changes present in
    > release should be considered to be present in mainline.  The differences
    > between mainline and release are much stronger than the differences
    > between release and 

    > So basically: have I misunderstood what star-merge is supposed to be
    > capable of?  I had expected that after a star-merge, you couln't
    > accidentally re-merge the same changes, but it looks as if you can in
    > some cases.

I'm not sure how "deep" an answer you want.  You somewhat
misunderstood.  We can talk about "patch theory" if you want to have a
better grasp on what's logically possible (and what arch does) -- but
the formulaic/pragmatic answer here is that "--forward" and
"--three-way" options are likely to do what you are looking for (and
it's always good to review with `what-changed --diffs' before
committing until, especially until you have a good feel for how merges
work).


-t