From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59922 invoked by alias); 27 Dec 2019 10:14:58 -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 59910 invoked by uid 89); 27 Dec 2019 10:14:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*Ad:D*uk, H*Ad:D*org.uk X-HELO: mail-lj1-f182.google.com Received: from mail-lj1-f182.google.com (HELO mail-lj1-f182.google.com) (209.85.208.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Dec 2019 10:14:56 +0000 Received: by mail-lj1-f182.google.com with SMTP id y4so12370114ljj.9 for ; Fri, 27 Dec 2019 02:14:55 -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=G/9WDyd9QDyjrS9nYfikigvCN+o5wagTBtJMUUb6TVU=; b=O2XB/WRgq1Sx39LSKsAJumdMZWBxYeQJSOFFmsI6Xo3V0ldNFVCKZEAyvtQDLDui6L bYKw60FBDdNRd9taPbJSVNLsMr8NZawGLKSdU92uN2cMq/LifDb+EIDggE1tvRu+mWvI zabaOQMQr7VqcFsUUCUwiIINpFqtr1/qefwsUF5sJpMOCmXtYfo3z5LdCHdJqXZJUxuJ anuvZIGxZlQiTLonKtWzCFs635Ja/quoJOYXZzprv2lMtOmtAEmN8SOFRJb0ZGxUSPYs wPymqp5bQpiYrBE9DsCA6nWc6TNB7Lj8R/muuTiOpVhuhV6xx0m09PrytBumKOxGE0b8 jqyA== Return-Path: Received: from ?IPv6:2a00:1370:8116:64e8:711a:b76a:e3fd:9ed5? ([2a00:1370:8116:64e8:711a:b76a:e3fd:9ed5]) by smtp.gmail.com with ESMTPSA id l21sm14475001lfh.74.2019.12.27.02.14.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Dec 2019 02:14:53 -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: Fri, 27 Dec 2019 10:14:00 -0000 Cc: GCC Development , Alexandre Oliva , "Eric S. Raymond" , Jeff Law , Segher Boessenkool , Mark Wielaard , "Richard Earnshaw (lists)" , Jakub Jelinek Content-Transfer-Encoding: quoted-printable Message-Id: <890D360E-EB79-4D19-9B5B-0C5A6B0F28D3@linaro.org> 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> To: Joseph Myers X-SW-Source: 2019-12/txt/msg00440.txt.bz2 > On Dec 27, 2019, at 4:32 AM, Joseph Myers wrote: >=20 > On Thu, 26 Dec 2019, Joseph Myers wrote: >=20 >>> It appears that .gitignore has been added in r1 by reposurgeon and then= =20 >>> deleted at r130805. In SVN repository .gitignore was added in r195087.= =20=20 >>> I speculate that addition of .gitignore at r1 is expected, but it's=20 >>> deletion at r130805 is highly suspicious. >>=20 >> I suspect this is one of the known issues related to reposurgeon-generat= ed=20 >> .gitignore files. Since such files are not really part of the GCC=20 >> history, and the .gitignore files checked into SVN are properly preserve= d=20 >> as far as I can see, I don't think it's a particularly important issue f= or=20 >> the GCC conversion (since auto-generated .gitignore files are only=20 >> nice-to-have, not required). I've filed=20 >> https://gitlab.com/esr/reposurgeon/issues/219 anyway with a reduced test= =20 >> for this oddity. >=20 > This has now been fixed, so future conversion runs with reposurgeon shoul= d=20 > have the automatically-generated .gitignore present until replaced by the= =20 > one checked into SVN. (If people don't want automatically-generated=20 > .gitignore files at all, we could always add an option to reposurgeon not= =20 > to generate them.) Removing auto-generated .gitignore files from reposurgeon conversion would = allow comparison of git trees vs gcc-pretty and gcc-reparent beyond r195087= . So, while we are evaluating the conversion candidates, it is best to dis= able conversion features that cause hard-to-workaround differences. >=20 > I'll do another GCC conversion run to pick up all the accumulated fixes=20 > and improvements (including many more PR whitelist entries / fixes in=20 > Richard's script), once another ChangeLog-related fix is in. -- Maxim Kuvyrkov https://www.linaro.org