From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19700 invoked by alias); 7 Feb 2020 13:56:14 -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 19690 invoked by uid 89); 7 Feb 2020 13:56:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=CL X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2020 13:56:12 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C2E1A328; Fri, 7 Feb 2020 05:56:10 -0800 (PST) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.78.81]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C1A4A3F6CF; Fri, 7 Feb 2020 05:56:09 -0800 (PST) Subject: Re: Git ChangeLog policy for GCC Testsuite inquiry To: Segher Boessenkool , Richard Biener Cc: Jeff Law , Richard Sandiford , "H.J. Lu" , paul@mad-scientist.net, GCC Development References: <6bc259050138912ea9b973ca4f43df72cb1bb7d8.camel@redhat.com> <20200205211801.GV22482@gate.crashing.org> <7743417118d2067cf0e9e1b840564f9f2d5e72dc.camel@redhat.com> <20200206135101.GY22482@gate.crashing.org> <20200206222548.GH22482@gate.crashing.org> <20200207134804.GN22482@gate.crashing.org> From: "Richard Earnshaw (lists)" Message-ID: Date: Fri, 07 Feb 2020 13:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200207134804.GN22482@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00082.txt.bz2 On 07/02/2020 13:48, Segher Boessenkool wrote: > Hi! > > On Fri, Feb 07, 2020 at 10:19:56AM +0100, Richard Biener wrote: >> On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool >> wrote: >>> Yeah, don't look at me then :-) >>> >>> I *like* having most of those steps, most of this should only be done by >>> people who are awake. >>> >>>> it's definitely a part that requires >>>> more typing compared to svn. >>> >>> Instead of "git am" I had "patch -p1 <", distributing the changelog parts >>> I just did in vi (as with git), then "svn ci", which pick up all modified >>> files directly (sometimes an "svn add" first). It's pretty much the same >>> for me. >> >> I'm a believer on committing from the tree I actually tested, > > But you cannot. Depending on which machine I use, a regstrap (all > languages) is between 2h and 40m, so when you push it upstream there > will usually be commits by other people as well. > > I also test just master plus what I want to commit, which works fine > most of the time. The master you test with is older than the one you > commit to (and yes, this sometimes matters :-/ ). > >> so it >> was with SVN: patch, test, svn up, edit changelogs (cut&paste from the >> patch header), svn diff | less (check wha'ts abotu to be committed), svn commit >> with GIT its now: patch, test, git add/commit, git pull --rebase, edit >> changelogs >> (cut&paste from the patch header), git commit --amend, git push -n -v, >> git show , git push >> >> So I wonder to "optimize" this somewhat. > > Having the patch as a file instead of just as a git commit makes the > cut-and-paste step a little easier (and more reliable). > > Once you have done this many many times, you can skip some of the > verification steps because you just *know* the state of everything. So > things will be a little faster over time, or at least it will feel that > way. > > Handling the changelog as you want will make things more streamlined, > certainly. It also makes it easier to mess things up... We'll see what > will happen, I guess :-) > >>>> ChangeLog file populating could be even >>>> done on the server-side I guess (and not appropriately formatted logs >>>> for the extraction/moving process rejected). >>> >>> Yup. As long as it's fool-proof, and we have some way to correct small >>> disasters (both of those!) >> >> I'd definitely prefer server-side operation, and yes, that "script" looking >> at the commit would need to have a "extract changelog parts" part >> for a pre-accept hook and the actual part amending the commit with >> the changelog file changes (not sure if that's even possible in a hook?). > > If you can think of it, it is possible. It's not even too hard I think. > > You want the commit hook to actually populate the changelog files, which > are still normal checked-in files, aha! That's a great idea. That > completely gets rid of my "fix mistakes" worries, and it will probably > also get rid of the "yet another flag day" inconvenience. > >> Fixing mistakes in the ChangeLog files could be as easy as allowing >> changes to ChangeLog files without that magic. > > Yeah :-) > >> Anyway, I hope to put sth together with bash & [g]awk > > gl;hf > > Should we require some simple markup in the commit message before the > changelogs? Maybe > > CL gcc/ > * blablalba etc. > CL gcc/testsuite/ > * gcc.target/... > etc. > > (Dunno if just "^CL " is too short?) I was thinking "@CL ", but ^CL would work just as well. Any script should, in addition to extracting the author and email also grep for "Co-authored-by:" annotations and add those as additional contributors, of course. R. > > > Segher >