basic-improvements merge status
Tom Lord
lord@emf.net
Mon Dec 16 02:19:00 GMT 2002
> ... but I just discovered that I don't know how. "cvs update
> -j gcc-3_4-basic-improvements-branch" tries to merge all of
> the merges from the trunk to the branch BACK into the trunk,
> causing a ton of spurious conflicts. What's the right way to
> do this? (I'm seriously considering "diff -ruN 3.3/ 3.4b/ |
> (cd top-of-trunk/ && patch -p1 -E"!)
I think that *is* the right way, roughly.
(In the alternate universe where gcc is managed with `arch') use:
larch star-merge gcc--basic-improvements gcc--mainline gcc-wd
That assumes that you want to start with basic-improvements and apply
the changes from mainline, which means that any real conflicts in
mainline will be kicked out to .rej files. If you'd rather have the
truly conflicting basic-improvements changes in .rej files, use:
larch star-merge gcc--mainline gcc--basic-improvements gcc-wd
If you've been cherry-picking those earlier merges, pipe
larch whats-missing ...
output into an `xargs' of
larch replay ...
If you now want to cherry pick rather than do a full merge, edit the
revision ids of the changes you want out of the output of:
larch whats-missing --summary
and apply `larch replay' to those.
Finally, if you want to do this merge in such a way the individual
changesets from basic-improvements appear as individual changesets
(i.e., clean single-purpose changes) on mainline, then use one of the
replay techniques -- but commit between each call to replay. That
will be a boon to people who have forks of mainline who themselves
cherry-pick from mainline changes. Your `diff' technique, and the
other `larch' techniques listed here, will smoosh together lots of
changes in a single commit -- forcing cherry-pickers to look to the
branches to get the clean changesets.
:-)
-t
More information about the Gcc
mailing list