From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23095 invoked by alias); 29 Dec 2019 18:55:25 -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 23081 invoked by uid 89); 29 Dec 2019 18:55:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*MI:sk:155B5BF, H*i:sk:155B5BF, H*f:sk:155B5BF, difficulty X-HELO: digraph.polyomino.org.uk Received: from digraph.polyomino.org.uk (HELO digraph.polyomino.org.uk) (81.187.227.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Dec 2019 18:55:24 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.90_1) (envelope-from ) id 1ildic-0006K3-B9; Sun, 29 Dec 2019 18:55:14 +0000 Date: Sun, 29 Dec 2019 18:55:00 -0000 From: Joseph Myers To: Maxim Kuvyrkov cc: GCC Development , Alexandre Oliva , "Eric S. Raymond" , Jeff Law , Segher Boessenkool , Mark Wielaard , "Richard Earnshaw (lists)" , Jakub Jelinek , frnchfrgg@free.fr Subject: Re: Proposal for the transition timetable for the move to GIT In-Reply-To: <155B5BFD-6ECF-4EBF-A38C-D6DD178FB497@linaro.org> 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> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2019-12/txt/msg00516.txt.bz2 On Sun, 29 Dec 2019, Maxim Kuvyrkov wrote: > With the "Missed merges" problem (see below) I don't see how reposurgeon > conversion can be considered "ready". It aims to be conservatively safe regarding merges, erring on the side of not adding incorrect merges if in doubt. Because of the difficulty in matching SVN and git merge semantics, it's inherently hard to define unambiguously exactly which merges are correct and which are cherry-picks or erroneous. I think extra merges are something nice-to-have rather than critical. The case you mention is one where there was a merge to a branch not from its immediate parent but from an indirect parent. I don't think it would be hard to support detecting such merges in reposurgeon. > Reposurgeon-6a conversion has authors "12:46:56 1998 Jim Wilson" and "2005-03-18 Kazu Hirata". It is rather obvious that person's name is unlikely to start with a digit. These are already fixed in bugdb.py since that conversion, as part of the general review of authors to fix typos and make them more uniform. > Reposurgeon-6a conversion misses many authors, below is a list of people > with names starting with "A". > > Akos Kiss This is an example where the originally added ChangeLog entry was malformed (had the date in the form "2004-0630"), so a conservatively safe approach was taken of using the committer rather than trying to guess what a malformed ChangeLog entry means and risk extracting nonsense. I expect other cases are being similarly careful in cases where there was a malformed ChangeLog entry or a commit edited ChangeLog entries by other authors so leaving its single-author nature ambiguous. Parsing ChangeLogs, especially where malformed entries are involved, is inherently a heuristic matter. -- Joseph S. Myers jsm@polyomino.org.uk