From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 55C203857C7A for ; Wed, 16 Jun 2021 21:45:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 55C203857C7A Received: by mail-oi1-x231.google.com with SMTP id d19so4098355oic.7 for ; Wed, 16 Jun 2021 14:45:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M95CLF17dpApKQOj9UTXBqdusB5NBNliaffoA2FeHzs=; b=j7xsDntkxHKXju0RY7Qjx3+wJ5YrXNOw7pm1uCl0Xrcx2oy/KNbQXw+raxEsIvITKS E/YJEpHmlCe9ucLI4eG5OtU1yb7PnFMAcYOLbdUND+lVMDpzVSD2AE/nVoF0L1eA7qbf Gr1bA7xYoI459EWY1PsQFazeDEU0ltomdOgLvy2M/8L99i1sZqejTKZQI5nJ1t7cwhGD pbyK4YEgeaizMs18CpVqNKTyhvpPGhthJ8H4AOVl7ZbvRSU7GWI5RFKN9+t2WBcnTZkk pSrXRbF1v7aCnfQcWIsEierlE73liHh/MhuvUqBwtYtywV1PhrdvIKv7DncmhwIi+dgF R8EQ== X-Gm-Message-State: AOAM5335CLTB6/8LoagHotXHe0bLEr4WXVrS9JuuH/ObHtIi7p97P8nb 9TE+zC5HixkbYAvefLqM7Qw= X-Google-Smtp-Source: ABdhPJymyT7yzPFqHSAt7QCD6kTcZ8zDTfO0WhxWK78p93ca8pnv1gxesSM5+JfR4AUGIWMH4+KQog== X-Received: by 2002:a54:4692:: with SMTP id k18mr8370268oic.118.1623879951699; Wed, 16 Jun 2021 14:45:51 -0700 (PDT) Received: from [192.168.0.41] (97-118-105-195.hlrn.qwest.net. [97.118.105.195]) by smtp.gmail.com with ESMTPSA id c34sm791843otu.42.2021.06.16.14.45.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 14:45:51 -0700 (PDT) Subject: Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog To: Jason Merrill Cc: Hans-Peter Nilsson , Jakub Jelinek , gcc Mailing List , Jonathan Wakely References: <20210610100851.GD7746@tucnak> <1230cb99-ed83-3e4e-8362-94f03ee021bc@gmail.com> <3228435b-aba0-6157-3266-c0f025822829@gmail.com> <5f89ddc0-aed4-2c20-0979-dfafb29046ee@gmail.com> <20210610173005.GI7746@tucnak> <20210610190941.GJ7746@tucnak> <58b63929-01f5-038c-931c-9ff8349d9f95@gmail.com> From: Martin Sebor Message-ID: Date: Wed, 16 Jun 2021 15:45:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 21:45:54 -0000 On 6/16/21 2:49 PM, Jason Merrill wrote: > On 6/15/21 11:42 PM, Jason Merrill wrote: >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc > > wrote: >> >>     On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote: >>      > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote: >>      > >>      >> On 6/11/21 11:32 AM, Jonathan Wakely wrote: >>      >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote: >>      >>>> My objection is to making our policies and tools more >> restrictive >>      >>>> than they need to be.  We shouldn't expect everyone to study >> whole >>      >>>> manuals just to figure out how to successfully commit a >> change (or >>      >>>> learn how to format it just the right way).  It should be easy. >>      >>> >>      >>> I agree, to some extent. But consistency is also good. The >>     conventions >>      >>> for GNU ChangeLog formatting exist for a reason, and so do the >>      >>> conventions for good Git commit messages. >>      >>> >>      >>>> Setting this discussion aside for a moment and using a >> different >>      >>>> example, the commit hook rejects commit messages that don't >> start >>      >>>> ChangeLog entries with tabs.  It also rejects commit >> messages that >>      >>>> don't list all the same test files as those changed by the >> commit >>      >>>> (and probably some others as well).  That's in my view >> unnecessary >>      >>>> when the hook could just replace the leading spaces with >> tabs and >>      >>>> automatically mention all the tests. >>      >>>> >>      >>>> I see this proposal as heading in the same direction. >> Rather than >>      >>>> making the script fix things up if we get them wrong it would >>     reject >>      >>>> the commit, requiring the user to massage the ChangeLog by >>     hand into >>      >>>> an unnecessarily rigid format. >>      >>> >>      >>> You cannot "fix things up" in a server-side receive hook, >> because >>      >>> changing the commit message would alter the commit hash, which >>     would >>      >>> require the committer to do a rebase to proceed. That breaks the >>      >>> expected behaviour and workflow of a git repo. >>      >>> >>      >>> You can use the scripts on the client side to verify your commit >>      >>> message before pushing, so you don't have to be surprised >> when the >>      >>> server rejects it. >>      >> >>      >> That sounds like a killer argument.  Do we have shared >> client-side >>      >> scripts that could fix things up for us, or are we each on our >> own >>      >> to write them? >>      > >>      > I hope I got your view wrong.  If not: the "scripts fixing >>      > things up for us" direction is flawed (compared to the "scripts >>      > rejecting bad formats"), unless offered as a non-default option; >>      > please don't proceed. >>      > >>      > Why?  For one, there'll always be bugs in the scripting. >>      > Mitigate those situations: while wrongly rejecting a commit is >>      > bad, wrongly "fixing things up" is worse, as a general rule. >>      > Better avoid that.  (There's probably a popular "pattern name" >>      > for what I try to describe.) >> >>     The word that comes to mind is Technophobia.  Is it wise to trust >>     compilers to transform programs from their source form into >>     executables?  What if there are bugs in either?  What about the OS? >>     The whole computer, or the Internet?  Our cars?  Fortunately, there's >>     more to gain than to lose by trusting automation.  If there weren't >>     human progress would be stuck sometime in the 1700's. >> >>     But we're not talking about anything anywhere that sophisticated >>     here: a sed script to copy and paste a piece of text in >>     the description of a change from one place to another.  It's been >>     done a few times before with more important data than ChangeLogs. >> >> >> git gcc-commit-mklog already automates most of the process.  It could >> also automate adding [PRxxxxx] to the first line.  Is that what you're >> asking for? > > Like, say: I don't think this solves the problem Xionghu Luo was asking about: https://gcc.gnu.org/pipermail/gcc/2021-June/236346.html i.e., they did have a [PRnnnn] in the one line subject but not in their ChangeLog entries. It also not clear if they used mklog.py at all. IME, mklog.py already puts in a [PRnnnn] near the top of a patch if it finds in one of the tests. Though it doesn't seem to put in the ChangeLog entries. Odd. I was suggesting to make this (and the other things the commit hook rejects commit for) happen automatically by running a script at the same time as git commit. But to be clear, I'm not asking for anything for myself. Although I use mklog.py I have my own script that does what I suggest that I could go back to. I responded to this thread because I think these minute details could be automated for everyone's benefit. Before moving to Git we talked about doing much more, including automatically running a format/style checker on the patch and (IIRC) Jeff even wanted it to do some basic tweaks on its own (like replace spaces with tabs). Martin