From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87769 invoked by alias); 16 Dec 2019 17:08:12 -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 87759 invoked by uid 89); 16 Dec 2019 17:08:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=improving, percentage, H*f:sk:0fb8107, H*MI:sk:0fb8107 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; Mon, 16 Dec 2019 17:08:10 +0000 IronPort-SDR: qopA3yNODn4e4RGuTlEA5wEy93d6xbWfLw6XTLdz2nQKTpGsljzF9kvr4i70jgugWadKIW9VcO f8PuFEehCGztVurj7/U1wTLP8fvoTSYplE4TBQdQ6lGqsza1JeFMTLWWdulglCM7IRLpj+z5NI viGoskym6zgWtzH3GaDuNzOtRZvlv4PFrrKZDn5Iap/NoE/x/n5IqGEqvk1TaDOaPF4csvsHcn 4qkfDSwyot2O2UkH9ePKghHVcP6r8LxoJTMtp5I4a10solptGP+9LubVB7WcIGo49HFN8Mzfb+ oVA= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 16 Dec 2019 09:07:54 -0800 IronPort-SDR: JFcnuYYn3NNr0YGEywGSNk7BLIKD5yNy60NeSSexnZpxJsUi8K0qSA/FQ1LYdrrmytCSXikGAk 0SJTSUdekzipPVHvfdPRa+YyKADxL4dUizxtiHtgKeIjTD3tGKYfeIwy0uZ3GZXRTFbGWRgczm 96fpfpX3t0I4Tfpm09pj2A3z19upbdX08likP0lAyLyHsaEMV/YXLP7R5eEJSiL7VPbDYijQ2+ u51yRHO0ijDDAsUpEh2J746AMChm7hsx41liy/rNjutkKGdeLpRnfQ95mssbk+KEmUIYW7G7fy EmE= Date: Mon, 16 Dec 2019 17:08:00 -0000 From: Joseph Myers To: Jeff Law CC: Mark Wielaard , Maxim Kuvyrkov , "Richard Earnshaw (lists)" , , Subject: Re: Proposal for the transition timetable for the move to GIT In-Reply-To: <0fb81074d87c96b3312565800b8bfc25cfcbe179.camel@redhat.com> Message-ID: References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> <9E009921-96EA-44A2-A06A-232711227E69@linaro.org> <0fb81074d87c96b3312565800b8bfc25cfcbe179.camel@redhat.com> 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/msg00246.txt.bz2 On Mon, 16 Dec 2019, Jeff Law wrote: > On Mon, 2019-12-16 at 11:29 +0000, Joseph Myers wrote: > > On Mon, 16 Dec 2019, Mark Wielaard wrote: > > > > > Should we go with the gcc-reparent.git repo now? > > > > I think we should go with the reposurgeon conversion, with all Richard's > > improvements to commit messages. gcc-reparent.git has issues of its own; > > at least, checking the list of branches shows some branches are missing. > > So both conversions can still be considered works in progress. > So it seems like your position is that the reposurgeon conversion is as > good as or better than conversion from Maxim's scripts. Yes. It should be possible to confirm branch tip conversions and other properties of the repository (e.g. that all branch tips are properly descended from the first commit on trunk except for the specific branches that shouldn't be) once my current conversions have finished running. I think there may well be things to *learn* from Maxim's conversion to improve the reposurgeon one further (if they don't take that long to implement). In particular, we should look carefully at the commit attributions in both conversions and Maxim's may well give ideas for improving the reposurgeon changelogs command (Richard came up with three ideas recently, which I've just filed in the reposurgeon issue tracker). But I also think: * reposurgeon is a safer approach than ad hoc scripts, provided we get clean verification of basic properties such as branch tip contents. * Richard's improvements to commit messages are a great improvement to the resulting repository (and it's OK if a small percentage end up misleading because someone used the wrong PR number, sometimes people use the wrong commit message or commit changes they didn't mean to and so having some misleading messages is unavoidable). * As we're part of the free software community as a whole rather than something in isolation, choosing to make a general-purpose tool work for our conversion is somewhat preferable to choosing an ad hoc approach because it contributes something of value for other repository conversions by other projects in future. -- Joseph S. Myers joseph@codesourcery.com