[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Julian T. J. Midgley
Subject: [Gnu-arch-users] Re: Mixing star-merge and selective replay
Date: Fri, 16 Apr 2004 11:47:17 +0000 (UTC)

In article <address@hidden>,
Tom Lord  <address@hidden> wrote:
>Once you get into the area of mixing and matching merge techniques in
>weird ways .... you're in "expert" territory.  The practical thing I'd
>suggest is that you get to a point where you can answer, in your head,
>what each merge command you think you want to run will do in each
>particular case.  E.g., it shouldn't surprise you what star-merge did
>there .... it's quite predictable ... but you have to not regard
>star-merge as a black-box to get to that point.

A fair cop ;-)

Ok, so having thought about it for a while, it was indeed no surprise.

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.

You can get away with it about once (using sync-tree to force
star-merge to pick ANCESTOR from the FROM branch, rather than
REFERENCE), but later star-merges will keep attempting to undo the
omitted patch.  Further cunning use of sync-tree prior to each
star-merge might just achieve the desired effect, but would be
unpleasant, and irritating to have to keep track of.

It looks like the best solution may be to stick to using replay, and
to use sync-tree to cause it to forget about trying to apply the
omitted patches. Something like:

tla tag proj--foo--0.1--patch-10 proj--bar--0.1

Create patches 11 through 15 on proj--foo.
Apply all but patch-11 to proj--bar.
In proj--bar: 
tla sync-tree proj--foo--0.1--patch-11
tla commit -s "synced patch-11"

Thereafter, the two trees can be kept in sync without having to
remember which patches to apply, with the algorithm below, which uses
sync-tree to avoid mutual merges.  I haven't tried this in practice
yet, but I think it should work; if others can spot a flaw, please let
me know; otherwise it should make a nice compromise between having to
keep track by hand of which patches to apply (or not) and carefree
star-merging.  (Forgive me if, as I suspect, I've just re-invented the
wheel here.)

To merge all unmerged changes from foo to bar (except for those
deliberately omitted):

In proj--bar:
 tla replay `tla missing -f proj--foo--0.1` 
 tla commit -s "merged from foo"
 (creates proj--bar--0.1--patch-NN)
In proj--foo:
 tla sync-tree proj--bar--0.1--patch-NN  # To prevent mutual merges
 tla commit -s "synced with bar" 

To merge all unmerged changes from bar to foo, just the converse

In proj--foo:
 tla replay `tla missing -f proj--bar--0.1` 
 tla commit -s "merged from bar"
 (creates proj--foo--0.1--patch-XX)
In proj--bar:
 tla sync-tree proj--foo--0.1--patch-XX   
 tla commit -s "synced with foo" 

And whenever a change needs to be made on on branch but not the other,
the sync-tree trick can be used to avoid pulling it across.  Thanks to
arch's use of patch-logs, it should scale to more than two branches.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]