From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11024 invoked by alias); 16 Dec 2002 09:58:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 11017 invoked from network); 16 Dec 2002 09:58:45 -0000 Received: from unknown (HELO emf.net) (205.149.0.20) by sources.redhat.com with SMTP; 16 Dec 2002 09:58:45 -0000 Received: (from lord@localhost) by emf.net (K/K) id BAA04232; Mon, 16 Dec 2002 01:58:45 -0800 (PST) Date: Mon, 16 Dec 2002 02:19:00 -0000 From: Tom Lord Message-Id: <200212160958.BAA04232@emf.net> To: gcc@gcc.gnu.org cc: zack@codesourcery.com, mark@codesourcery.com In-reply-to: <93090000.1040028121@warlock.codesourcery.com> (message from Mark Mitchell on Mon, 16 Dec 2002 00:42:02 -0800) Subject: Re: basic-improvements merge status References: <93090000.1040028121@warlock.codesourcery.com> X-SW-Source: 2002-12/txt/msg00868.txt.bz2 > ... 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