Re: basic-improvements merge status

[Tom Lord <lord@emf.net>]

       > ... 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