From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7578 invoked by alias); 29 Dec 2019 23:00:23 -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 7507 invoked by uid 89); 29 Dec 2019 23:00:17 -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=helping, We're, Were, modern X-HELO: esa1.mentor.iphmx.com Received: from esa1.mentor.iphmx.com (HELO esa1.mentor.iphmx.com) (68.232.129.153) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Dec 2019 23:00:15 +0000 IronPort-SDR: v613XDRsrFc6zCzOZ99+AW6/6Ei861d8aM+JjXFkMXo6lNwCBICwWLOxo1yGOUvlERc8d/jmBc yDQS6nxUYFlp7qELmAhzqK/mTuSNa18Uhk3W7hx3oNYzGysiPAZSgldjy8ilIpZlSAq/Yehrmu j26s8djMg8VnOMZaPD8PWS/pw1cCM0BjqToWnvksnJD+2tQA+XW2w1Yz7FKQcGz9UUPN0dN+J5 UfKuYUeAGT1cvzFY/wtKZAqw52tT+1waxmgM8WvBEgZ2+Hds9nEIRf+xlprCJ0QJX/eeE0fqSu tco= Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 29 Dec 2019 15:00:14 -0800 IronPort-SDR: QutyQepsZd7LZ2hxDzdsqXoecx+ORH9aANAVb15npQw/v+rhaNSub4BD3fvFGdt0Q0U9XP8J3E G4BmSyA1h9X2Cf3kNYA8p/iCZ7b+IFPTpnjBtqsMPhJeBZT+brD8/z3U3LncbA+2JM0wl0MUdi fKqJrUxcgf5HwWbLMUfGuoPnh4fLFpVfDrcjYaqREZzE455l2ix3bw3io/FtGwJVf8sWvl6Fe3 PrrT78Mv54YQz+QNO66LlOPfLn13AoDWe6WP8C4t9ikreIWHPZ+/Jov2ELr+VLt8YNE69gvEdV +uY= Date: Sun, 29 Dec 2019 23:00:00 -0000 From: Joseph Myers To: "Eric S. Raymond" CC: Maxim Kuvyrkov , GCC Development , Alexandre Oliva , Jeff Law , Segher Boessenkool , Mark Wielaard , "Richard Earnshaw (lists)" , Jakub Jelinek , Subject: Re: Proposal for the transition timetable for the move to GIT In-Reply-To: <20191229224740.GB51787@thyrsus.com> Message-ID: References: <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> <20191229224740.GB51787@thyrsus.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/msg00527.txt.bz2 On Sun, 29 Dec 2019, Eric S. Raymond wrote: > Joseph Myers : > > 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. > > We're working on it. And the other example branch mentioned (redhat/gcc-9-branch) is a different case: if the merge from gcc-9-branch to redhat/gcc-9-branch had been done in the idiomatic way with modern SVN (i.e. naming the branch to merge from and letting SVN deal with identifying the revisions involved), I think reposurgeon would have handled it just fine. But the commit messages indicate the merge was done in an old-fashioned way (naming individual ranges of revisions to merge manually), which resulted in merge properties very slightly different from what SVN creates automatically. Now I understand what the difference is I expect we'll be able to fix that case as well. > As Joseph says, one of reposurgeon's design principles is "First, do no harm." > > And yes, changelogs are full of malformations and junk like this. I > saw and dealt with a lifetime's worth while converting the Emacs > history from bzr to git. > > If you try to interpret any random garbage in, you will assuredly > get garbage out when you least expect it. Often the cost of this > sort of mistake is not fully realized until it is far too late > for correction. This is *why* reposurgeon is conservative. > > The correct thing for reposurgeon to do is flag unparseable entry > headers for human intervention, and as of today it does that. Furthermore, we can compare authors in the different conversions to identify cases where, based on a manual review, Maxim's heuristics produce better results for a particular commit, and add those to the list of fixups in bugdb.py - and that way benefit both from reposurgeon making choices that are as conservatively safe as possible, which seems a desirable property for problem cases that haven't been manually reviewed, and from different heuristics helping suggest improvements in particular cases. -- Joseph S. Myers joseph@codesourcery.com