From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 2D759384F00B for ; Wed, 16 Jun 2021 02:03:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2D759384F00B Received: by mail-oi1-x22c.google.com with SMTP id x196so763596oif.10 for ; Tue, 15 Jun 2021 19:03:42 -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=MrYJjr/oY+/xyMsczpf5BTAcBHsHL/Xjr3m+oYPvQfo=; b=L5juMiFZHAkQ5Wa/UnaqVs6aWz8uIbmir6cAz2mGYJ0XwlNPgQ8ooG6rd6/H0ad8tm V5ckxofmTP4xeUruLFaJjRmJ0Hme6N9QOvGPSIkQYFs1OAajNq+hNM59b6ZUKGkqtG9E RHDboAsPbz/p2yi4ONLLrRCgbT+ei9alCsoL7ev+culubA5dmWR1DTPo6ke/A5np8wum HAHO6M4vfcjTb9OJGoLS3kvtrSOhY0rSGl7dnrtCWtkinh9y7NWDUL5JOL9qGdWpj+D+ rf793BA9DfNg7onRZoPE1nXYv75LLt48g3MbmUlVaTjA47oNd30nXbbYdREvPxCETjkr 2Zjw== X-Gm-Message-State: AOAM5300kjT920tZ9gQe8xUopcQ+CcEHgaoL7xWou6DYR1hWgFDC9WTN Vp6AsK1/gVym94yPPDUYzXOIwO7qM4I= X-Google-Smtp-Source: ABdhPJzx3NvwkeiptPPrpv+l7kacYpQ+8BCegpcyLwRjz9Xb2FbIyOy/2AJ5FhMZ7ppdvnJH6DqlCw== X-Received: by 2002:aca:6041:: with SMTP id u62mr1351418oib.23.1623809021336; Tue, 15 Jun 2021 19:03:41 -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 v8sm59965oth.69.2021.06.15.19.03.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jun 2021 19:03:40 -0700 (PDT) Subject: Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog To: Hans-Peter Nilsson Cc: Jonathan Wakely , Jakub Jelinek , gcc@gcc.gnu.org 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: Tue, 15 Jun 2021 20:03:39 -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: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 02:03:43 -0000 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. Martin