Re: [Gnu-arch-users] following branched branches

[Tom Lord]

    > From: Dustin Sallings <address@hidden>

    > So, I've got a branch of address@hidden/tla--devo--1.1 that
    > has some changes not present in 1.2, but I would like to follow
    > 1.2 with my changes.  Branching my tree and trying to star-merge
    > 1.2 in tells me ``unable to merge unrelated trees.''  I assume
    > I'd get the same the other way around.

    > What's the standard procedure for doing such a thing?

    > The trees don't seem quite so unrelated since they share a common 
    > descendant and my branch is a superset of 1.1.

Rob answered this but I don't like the answer he gave because,
although it happens to give a right answer in this case, that's
basically by coincidence.  It's not really the right way to do it.
It can screw up royally in some situations that are only slightly
different.

Forgive the long-winded answer here but let's look into this problem.

(The answer doesn't involve star-merge at all.  I'll leave for a later
message an explanation of why star-merge is a bad choice here.)


We start with:

   tla--devo--1.1 (mine)                tla--dustin--1.1
      (version V)                          (version W)
   ---------------------                ----------------
     [...]

     patch-A      ----- tagged by ----> base-0
     ("V-A")                            ("W-0")

     [...]                              [... mix of local
                                             changes and 
                                             merges from
                                             tla--devo ...]

     patch-B      ---- merged into ---> patch-A
     ("V-B")        (most recent merge) ("W-A")

     [...]                              [...]

     patch-C                            patch-B
     ("V-C")                            ("W-B")

     [...]

     patch-D
     ("V-D")


You happen to know that tla--dustin--1.1 hasn't been merged into
tla--devo--1.1 more recently than V-B and we'll take advantage of
that in this solution.

One thing we can notice right off the bat is that your local changes
are:

        delta (V-B, W-B)

also known as a certain output from `tla changes':

        % tla get tla--dustin--1.1 my-old-tree

        % cd my-old-tree

        % tla changes -o ,my-changes --diffs \
           address@hidden/tla--devo--1.1

In other words, "What are the changes in tla--dustin--1.1 that aren't 
there in its most recent tla--devo--1.1 ancestor?   Those are my 
local changes."

You can look over that changeset and confirm by eye that:

        (a) it really does have all of your local changes to
            the source

        (b) it should add patch-logs from tla--dustin--1.1
            but if tla--dustin--1.1 is really in sync with "V-B"
            it should neither add or delete any tla--devo--1.1
            patch logs

            (If tla--dustin--1.1 _isn't_ really in sync, then
             that creates a separate subproblem to solve but
             I won't get into that in this message.)


Meanwhile, I've started tla--devo--1.2:


   tla--devo--1.1 (mine)                tla--devo--1.2
     (version V)                          (version X)
   ---------------------                --------------
     [...]

     patch-C     ---- tagged by ----->  base-0
     ("V-C")                            ("X-0")

     [...]                              [...]

     patch-D
     ("V-D")


Right away, this suggests one simple way to solve the problem you want
to solve.  Instead of branching from tla--dustin--1.1 to make
tla--dustin--1.2, you could branch from tla--devo--1.2:


   tla--devo--1.2                       tla--dustin--1.2
     (version X)                         (version Y)
   --------------                       ----------------
                   
                   
   base-0          
   ("X-0")         
                   
   [...]

   patch-A      ---- tagged by ----->    base-0
   ("X-A")                               ("Y-0")



and just use that changeset that was earlier created with `changes':


        % cd ..

        % tla get tla--dustin--1.2 my-new-tree

        % cd my-new-tree

        % cp ../my-old-tree/,my-changes .

        % tla redo ,my-changes

        % tla changes --diffs
        # 
        # read over the output to sanity check
        # 

        % tla commit -L 'merge my changes into my 1.2 branch'


================================


So, that solution amounted to a two-step solution (`changes' + `redo')
involving two trees:

        tla get tla--dustin--1.1 wd1
        cd wd1
        tla changes -o ,changes address@hidden/tla--devo--1.1
        cd ..
        tla get tla--dustin--1.2 wd2
        cd wd2
        cp../wd1/,changes .
        tla redo ,changes


The two-step, two-tree solution is very close to a one-tree, one-step
solution.   Given that we know that tla--dustin--1.1 is "up to date"
with patch-B of tla--devo--1.1, a one-tree, one-step solution is:

        tla get tla--dustin--1.2 wd2
        cd wd2
        tla delta-patch address@hidden/tla--devo--1.1--patch-B \
                        tla--dustin--1.1

an interesting idea this suggests to me is to add a new command
that would infer "patch-B" the way we used `changes' to figure
it out.  Something like:


        tla get tla--dustin--1.2 wd2
        cd wd2
        tla move-local-changes address@hidden/tla--devo--1.1 \
                               tla--dustin--1.1


-t