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

[Tom Lord]

    > From: Jan Hudec <address@hidden>

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

    > You have probably overestimated it's abilities. What it does is, that it
    > computes the "most recent common ancestor" and then applies delta
    > against this ancestor.

    > The limitation is, that only the two branches merged are by default
    > constidered candidates for the ancestor. So if you merge something from
    > release to mainline and smallfeatures, star-merge won't notice. You can
    > however tell it so (using --reference option).

That's true, too.   The original poster had:

        mainline
           \
             release
                \
                 smallchanges

and got confused about merging smallchanges into mainline after
already merging release into mainline.

The --reference option would allow you to say: "merge smallchanges
into this mainline tree, but pretend that this mainline tree is a
`release' tree"  (i.e., "skip things already found in release").

That'll work.   But be careful:  if the future involves just random
back-and-forth merges among these three development lines, then it's
time to really start to understand more deeply how merging works.

This is a general issue I've started to notice:  some systems just
turn on the equivalent of --forward or --three-way by default and
otherwise don't try to implement "smart merging".   In effect, they
wind up substituting by-hand labor for smart merging, just mitigating
that a little bit with '--forward'-style behavior.   Consequently,
many people aren't much used to how to think about "what you can do
with merging" -- their used to brute-forcing-it-by-hand.


-t