From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107416 invoked by alias); 29 Dec 2019 22:47:45 -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 107404 invoked by uid 89); 29 Dec 2019 22:47:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=junk, realized, interpret X-HELO: snark.thyrsus.com Received: from thyrsus.com (HELO snark.thyrsus.com) (71.162.243.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Dec 2019 22:47:41 +0000 Received: by snark.thyrsus.com (Postfix, from userid 1000) id 1F52C4704AD9; Sun, 29 Dec 2019 17:47:40 -0500 (EST) Date: Sun, 29 Dec 2019 22:47:00 -0000 From: "Eric S. Raymond" To: Joseph Myers Cc: Maxim Kuvyrkov , GCC Development , Alexandre Oliva , 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 Message-ID: <20191229224740.GB51787@thyrsus.com> Reply-To: esr@thyrsus.com 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00524.txt.bz2 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. > 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. 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. -- Eric S. Raymond