From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43140 invoked by alias); 19 Dec 2019 00:58:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 43130 invoked by uid 89); 19 Dec 2019 00:58:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=sounded, spu-4_5-branch, sk:b743e46, spu4_5branch X-HELO: esa3.mentor.iphmx.com Received: from esa3.mentor.iphmx.com (HELO esa3.mentor.iphmx.com) (68.232.137.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Dec 2019 00:58:44 +0000 IronPort-SDR: HVDYDRKjnditH1+UqjIP/QYqi8YHfQ09UeGkJQNZZjUt5PeJZOFV8r8jP8LwH3RzflLhbMkTXi S3frPg1ehvTasNWLus9PcXNwKqVUMiRlgOcPqfkJqpHmYS3K38UInYUyhk2tG4+9MdG8Z2nMP9 gJO/9uflqE9/cZFC9Qc2kaSGlYWVzkepR6pQ5mifGmvVevArwW+ADX3D+hJD3DaDWIR0ocVy6t 93VlTsGDyYirXjulp9MTPYG9SzJhAC37+7iEm8bH57nWtidar+T8WiDVp4SCJDXjbp5VoHa4Kl Q7I= Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 18 Dec 2019 16:58:42 -0800 IronPort-SDR: E4ZXWAYCYQBIwAjDbRS+ylzaeciqGIjqMu721PrUz0khR3Bv4cY1CZhOMn2DjoyI8cgnK02yJz 1vnGqafcquy222ZUkCoxAMo4QJo7JCRINAZ2reRAFHXiE5wDMQjBcOz/HvVQnqHAO9n4Rejz7m ld0qFbLQTnlQ90KW741L42PHzc0CrbZO63jFWKTWX3pYdw+A3FUSA1eFG6yLJ/XyYC3P5oxHnu RuTVJo8objLPbgfhcDD+/TJoZ3Uw7VTs8rMsdO4cp7Idk8b7V4T17+cOxkpn2R1+1BsuRSze87 0HU= Date: Thu, 19 Dec 2019 00:58:00 -0000 From: Joseph Myers To: Bernd Schmidt CC: , Subject: Re: Test GCC conversion with reposurgeon available In-Reply-To: <87888d12-b6f7-ff58-f7ed-de0e93f7ee60@t-online.de> Message-ID: References: <87888d12-b6f7-ff58-f7ed-de0e93f7ee60@t-online.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: joseph@codesourcery.com X-SW-Source: 2019-12/txt/msg00294.txt.bz2 On Thu, 19 Dec 2019, Bernd Schmidt wrote: > On 12/18/19 10:55 PM, Joseph Myers wrote: > > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git > > I cloned this one and started trying random things again. > The previous one had some strange-looking merge commits, but it sounded like > that was a known issue, and indeed the ones I had seen were fixed in this new > version. > I decided to write a small script to check whether there were any merge > commits with more than two parents, and there are a few which have three. One > commit seems to occur as a parent in all of these: > 422854db0e8605867e0834035aa2b1da1b71cbfb. An example is > b743e467e43e6211f2c2537f1f07bbceb4d3aa61, apparently from spu-4_5-branch. > > No idea whether there is an issue or whether this is worth looking at, but I > figured I'd point it out at least. b743e467e43e6211f2c2537f1f07bbceb4d3aa61 is r152464, from named-addr-spaces-branch. This merge is the first one that added an svn:mergeinfo property on named-addr-spaces-branch, which previously had only svnmerge-integrated (the svn:mergeinfo property was copied from the one that was on trunk at that time). That svn:mergeinfo property specifies merges from /branches/cxx0x-lambdas-branch, /branches/lto and /trunk, and the merge parents are for the first two of those. For /trunk, it only specifies two revisions, which is clearly not a valid merge and this version of reposurgeon avoids creating merge commits for cherry-picks. svnmerge-integrated specifies /trunk:1-151687,151691-152437, which would be a valid merge from trunk (there are no trunk revisions in the gap) but reposurgeon only looks at svnmerge-integrated if svn:mergeinfo is empty. I'll file a request that it take the union of revision ranges from the two properties, which ought to be easy to implement. Once it recognises that commit as a merge from trunk, it will should automatically discard the other merge parents because it now avoids adding a merge parent that is an ancestor of another merge parent. I.e. this is an artifact of someone having done a merge with svnmerge.py that brought in svn:mergeinfo from another branch where SVN's native merge tracking had been used, and should be straightforward to fix. -- Joseph S. Myers joseph@codesourcery.com