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

[Tom Lord]

    > From: Joshua Haberman <address@hidden>
    > Cc: address@hidden,

    > On Tue, 2003-12-09 at 13:51, Tom Lord wrote:
    > >     > From: Aaron Bentley <address@hidden>
    > >     > 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.)

    > I just don't get what makes this hard.

    > You have:
    > - a sequence of changesets that have been applied to smallfeatures
    >    (and its ancestors)
    > - information about which changesets have been applied, directly or
    >    indirectly, to mainline.

    > Why can't you merge from smallfeatures to mainline using the following
    > algorithm:
    > - determine the most recent ancestor
    > - for each changeset between the most recent ancestor and the newest 
    >    revision on smallfeatures:
    >     - if there is no patch log for this changeset in mainline, apply
    >         this changeset to mainline.  otherwise continue.


In one sense, you certainly can do that.   That's roughly what
`replay' does.

Tricky issues start to arise, though (and for example), if you have
already merged some changes from release to smallfeatures and from
release to mainline before you try to merge from smallfeatures to
mainline.


    > Why is "subtracting out" required?  The changesets that already exist in
    > smallfeatures and its ancestors contain information at enough
    > granularity to perform the desired operation: applying changes to
    > mainline that smallfeatures has but mainline does not.

    > I've asked this question repeatedly but never gotten an answer I
    > understand.

Perhaps, for the simplified scenario you are describing, `replay' is
what you want.  Replaying, rather than star-merging, smallfeatures
into mainline might have been another way to get the result you
wanted.

But suppose that I have merged from release into _both_ mainline and
smallfeatures and now want to merge from smallfeatures into mainline.

Arch can recognize, sure, that some changes from smallfeatures have
been applied to both.  What it can't tell is whether, when you merged
from release to smallfeatures you, took those changes "as is" or made
some further changes to those changes that only appear on
smallfeatures.  So when merging back from smallfeatures to mainline,
it would have to "subtract out" the changes from release and see if
you made any "changes to changes" that should be copied to mainline.

There does not exist a perfect way to do that "subtracting out";  the
options --forward and --three-way are the best predictable
approximations of which I'm aware.

-t