From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72942 invoked by alias); 30 Dec 2019 12:39:14 -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 72929 invoked by uid 89); 30 Dec 2019 12:39:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Spam-Relays-External:2a00, H*RU:2a00, HX-HELO:sk:mail-lj, H*r:2a00 X-HELO: mail-lj1-f194.google.com Received: from mail-lj1-f194.google.com (HELO mail-lj1-f194.google.com) (209.85.208.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Dec 2019 12:39:11 +0000 Received: by mail-lj1-f194.google.com with SMTP id u1so33158083ljk.7 for ; Mon, 30 Dec 2019 04:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p5r/yr88e1ytcPKm88bj9ijlYUCt2kG9swv4LDRKqPA=; b=emvm9XtW8lJgmZhJpUhRZW9sxC2Pi/A9Jcj6IByxKOW78gMKZzTuneXpjhFGRj79kj PpmAN+AEerEIelWsCLfnQ/BwCJy3D6Pr7DjnKpzvWgECFDUwb/j/34sJ1D2/ok/sfUUy vq/jSSTGuLBehsoHJ+fyuvbiPG8k+IJM8UMHQ8jHBPvlkkHNhAuox/wbIbga0Cztg7QM fhQGPeD+6Y+qaoZELd1N+aNu/zN8uVrIQWJKD6l9I1HTVe82o9aGwdRB0c8QuyRLlIe7 FXPa9G6lBYts7DCOQLCFfGLTdMO0/Z0eGVW9v8KFBqJrHCNTHr0vynDUWGi12FzH7q9d d0bA== Return-Path: Received: from ?IPv6:2a00:1370:8116:64e8:f435:bf44:821c:a9f3? ([2a00:1370:8116:64e8:f435:bf44:821c:a9f3]) by smtp.gmail.com with ESMTPSA id y25sm18479349lfy.59.2019.12.30.04.39.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Dec 2019 04:39:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: Proposal for the transition timetable for the move to GIT From: Maxim Kuvyrkov In-Reply-To: Date: Mon, 30 Dec 2019 12:39:00 -0000 Cc: "Richard Earnshaw (lists)" , GCC Development , Alexandre Oliva , "Eric S. Raymond" , Jeff Law , Segher Boessenkool , Mark Wielaard , Jakub Jelinek Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191216133632.GC3152@gate.crashing.org> <20191216135451.GA3142@thyrsus.com> <20191216140514.GD3152@gate.crashing.org> <20191216153649.GE3152@gate.crashing.org> <20191225120747.GA96669@thyrsus.com> <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <155B5BFD-6ECF-4EBF-A38C-D6DD178FB497@linaro.org> <2b6330f2-1a00-ac89-fd3c-4b70e5454f4b@arm.com> To: "Joseph S. Myers" X-SW-Source: 2019-12/txt/msg00533.txt.bz2 > On Dec 30, 2019, at 3:18 AM, Joseph Myers wrote: >=20 > On Sun, 29 Dec 2019, Richard Earnshaw (lists) wrote: >=20 >> gcc-reparent is better, but many (most?) of the release tags are shown >> as merge commits with a fake parent back to the gcc-3 branch point, >> which is certainly not what happened when the tagging was done at that >> time. >=20 > And looking at the history of gcc-reparent as part of preparing to compar= e=20 > authors to identify commits needing manual attention to author=20 > identification, I see other oddities. >=20 > Do "git log egcs_1_1_2_prerelease_2" in gcc-reparent, for example. The=20 > history ends up containing two different versions of SVN r5 and of many=20 > other commits. One of them looks normal: >=20 > commit c01d37f1690de9ea83b341780fad458f506b80c7 > Author: Charles Hannum > Date: Mon Nov 27 21:22:14 1989 +0000 >=20 > entered into RCS >=20 >=20 > git-svn-id: https://gcc.gnu.org/svn/gcc/trunk@5 138bc75d-0d04-0410-961= f-82ee72b054a4 >=20 > The other looks strange: >=20 > commit 09c5a0fa5ed76e566668cc67f3d72bf397277fdd > Author: Charles Hannum > Date: Mon Nov 27 21:22:14 1989 +0000 >=20 > entered into RCS >=20 >=20 > git-svn-id: https://gcc.gnu.org/svn/gcc/trunk@5 138bc75d-0d04-0410-961= f-82ee72b054a4 > Updated tag 'egcs_1_1_2_prerelease_2@279090' (was bc80be265a0) > Updated tag 'egcs_1_1_2_prerelease_2@279154' (was f7cee65b219) > Updated tag 'egcs_1_1_2_prerelease_2@279213' (was 74dcba9b414) > Updated tag 'egcs_1_1_2_prerelease_2@279270' (was 7e63c9b344d) > Updated tag 'egcs_1_1_2_prerelease_2@279336' (was 47894371e3c) > Updated tag 'egcs_1_1_2_prerelease_2@279392' (was 3c3f6932316) > Updated tag 'egcs_1_1_2_prerelease_2@279402' (was 29d9998f523b) >=20 > (and in fact it seems there are *four* commits corresponding to SVN r5 an= d=20 > reachable from refs in the gcc-reparent repository). So we don't just=20 > have stray merge commits, they actually end up leading back to strange=20 > alternative versions of history (which I think is clearly worse than=20 > conservatively not having a merge commit in some case where a commit migh= t=20 > or might not be unambiguously a merge - if a merge was missed on an activ= e=20 > branch, the branch maintainer can easily correct that afterwards with "gi= t=20 > merge -s ours" to avoid problems with future merges). >=20 > My expectation is that there are only multiple git commits corresponding= =20 > to an SVN commit when the SVN commit touched more than one SVN branch or= =20 > tag and so has to be split to represent it in git (there are about 1500=20 > such SVN commits, most of them automatic datestamp updates in the CVS era= =20 > that cvs2svn turned into mixed-branch commits). Thanks for catching this. This is fallout from incremental rebuilds (rathe= r than fresh builds) of gcc-reparent repository. Incremental builds take a= bout 1h and full rebuilds take about 30h. I'll switch to doing full rebuil= ds. -- Maxim Kuvyrkov https://www.linaro.org