[Gnu-arch-users] Re: Mixing star-merge and selective replay

[Julian T. J. Midgley]

In article <address@hidden>,
Stefan Monnier  <address@hidden> wrote:
>> So it turns out that there isn't a solution to the original problem -
>> you can't mix selective replays (the effect of which is to omit
>> certain patches) and star-merge.
>
>Well, of course you can.  The problem you're having has to do with using
>star-merge between two branches *in both directions*.  And if you think
>about it, it doesn't have to do with star-merge as much as with the notion
>of "propagate all changes from either branch to the other".

It has everything to do with star-merge as it happens, see below for
details.

>You should be able to do the following, at least:
>
>branch-2:   merge up to patch-19
>branch-2:   commit
>branch-1:   star-merge branch-2
>branch-2:   add the patch-20 log without the corresponding source changes
>branch-2:   commit
>
>Now a star-merge in branch-1 should not try to undo patch-20 and you can
>then move forward and forget about patch-20.

I thought this too for a while.  If you think about it a little
longer, you'll see that patch-20 will come back to haunt you next time
you star-merge in the other direction (to your branch-2 in this case).  

The problem (which is not a problem with star-merge itself) is that
star merge /calculates/ a patch to apply, rather than just picking
missing patches:
 

                b5  b6   b7    b8      b9
   branch ------+---+----|-----|-------+----------      
               /     \                /
          m1  /       \ m2           / m3
             /         \            /
 main -|----+-------|---+----|-----+---------- 
       p20  p21     p22 p23  p24   p25

Without using the sync-tree trick (i.e. adding the patch-20 log
without the changes), when I attempt the first star-merge (m1) from
main to branch, ANCESTOR will be (say) p19, the last patch I merged
from main to branch.  FROM will be p21, and so star-merge will
calculate diff(p19,p21) and apply this to branch.

The trick with sync-tree moves ANCESTOR forward to p20, so star-merge
calculates diff(p20,p21) and applies that to branch.  All fine so far.

When I star merge back to main in m2, ANCESTOR is p21, FROM is b6, and
the diff includes the reversed p20 changes (because diff(p21,b6)
doesn't know it should ignore those bits of the tree as it was after
p21 that were caused by p20), which I don't want.  So I use the
sync-tree trick again, this time to stick the b5 patch-log into the
main tree, which makes star-merge use b5 as ANCESTOR, rather than p21,
and so the patch applied is diff(b5,b6) which is exactly what I want,
and no more. [0]

However... when I later attempt m3 (merge from main to branch),
star-merge will pick b6 as ANCESTOR, and p25 as FROM, and diff(b6,
p25) includes those pesky p20 changes again (and the p22 changes,
which I do want).  This time, there isn't a sync-tree trick that will
work.  I can't sync-tree p23 back on to branch, because then p22 will
never be merged into branch if I do.  I could manually replay p22 on
to branch, then sync-tree p23 to branch, then star-merge, but I have
to have been paying very careful attention if I'm going to get this
right (especially if "p21" and "p25" are separated by several months
of development time) ;-)

So I think it's back to the replaying patches idea, unless someone
else can see a way out.

Julian


[0] For the benefit of anyone who hasn't studied star-merge in detail,
that paragraph will make more sense after a careful reading of the
star-merge help, in particular the bit that describes how ANCESTOR is
picked (which I'd not done properly until last night, or I'd never
have thought it'd have any chance of solving my initial problem in the
first place ;-)).

-- 
Julian T. J. Midgley                       http://www.xenoclast.org/
Cambridge, England.
PGP: BCC7863F FP: 52D9 1750 5721 7E58 C9E1  A7D5 3027 2F2E BCC7 863F