This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: basic-improvements merge status
- From: Tom Lord <lord at emf dot net>
- To: gcc at gcc dot gnu dot org
- Cc: zack at codesourcery dot com, mark at codesourcery dot com
- Date: Mon, 16 Dec 2002 01:58:45 -0800 (PST)
- Subject: Re: basic-improvements merge status
- References: <93090000.1040028121@warlock.codesourcery.com>
> ... 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