From: Robert Anderson <[EMAIL PROTECTED]>
I have two branches A and B. B is a feature branch which is intended
to fully merge into A. (The situation is actually much more complex
than this, but I HOPE this is enough to describe the problem.) [....]
Aside from the already mentioned options:
You could restore discipline to your branches by pretending momentarily
that the changes you cherrypicked into A were independently developed
and just happen to be the same as changes in B.
To make sure we are in sync -- I understand you to have something like
this:
A revisions: B revisions:
[...]
a-A ----tag----> b-K
[...] [...]
a-B <----pick--- b-L
[...] [...]
a-C <----pick--- b-M
[...] [...]
a-D b-N
Untested, but, won't this do what you want?:
% tla get A
% cd A
% tla remove-log-version B
% tla commit
% cd ..
% tla get B
% cd B
% tla star-merge --three-way A
or
tla star-merge --forward A
If you don't want to smudge your A archive that way you could do:
% tla get A
% cd A
% tla remove-log-version B
[set up a temporary archive and switch this tree there]
% tla commit # not to A but to A-tmp
% cd ..
% tla get B
% cd B
% tla star-merge --three-way --reference A A-tmp
or
tla star-merge --forward --reference A A-tmp
[trash the A-tmp logs, if you like]
There are lots of variations. It would be easier if the FROM
argument to star-merge could still be a project tree rather than
a revision --- that should probably be restored.
You can also merge from A to B using star-merge in segments,
separated by the cherry-pick merge points from B to A, mixed
with sync-trees for those merge points (or if not sync-tree, any
step that will add the A log which records a cherry-pick).
Once the common ancestor between the two branches is past the
cherry-pick points you'll be back in star-topology territory.
-t
_______________________________________________
Gnu-arch-users mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
