From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 818C53893655 for ; Wed, 16 Jun 2021 03:42:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 818C53893655 Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-47-O3eoW6ttMgCkzV6mvtXhgQ-1; Tue, 15 Jun 2021 23:42:42 -0400 X-MC-Unique: O3eoW6ttMgCkzV6mvtXhgQ-1 Received: by mail-pj1-f72.google.com with SMTP id r17-20020a17090aa091b029016eedf1dd17so2153272pjp.0 for ; Tue, 15 Jun 2021 20:42: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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EkaIk3cpSn1ARecYTN4+A2zIv+BBzUbQ0TbTwUIyjig=; b=DFy5AZD8CIhgSTrivG5jcPOyQqzHGvOL5mg4zF2s6YzcvRS21zIwGAgL4R66qw+zRU FocJ0uN5XDqNvpf8g4c4JgrJLX5BlM6NXcUgcNpG09W0qhyPRW3J+Cr9vKjFCHI4ETOE llC3c7tihygk05xFqPHNdosNj1yIQtjioMWTYNfwJHO6ZYZFPVFI5uTJHEBtO7zjgIpC diSydDl25MiiQymqwhzDw6UcybKv0K0+UENt5hkUKDDIqdRNRm5Fgy0mxhld1kg58fwQ IaTQB/1EmFXry5vGB5S1jvyTT47Tnupd/ppXMmmRz+qSWpZmA8bfLU91/8ihMsE+KV9J VVPQ== X-Gm-Message-State: AOAM532v9jHWpB/XKRnA6ceLw2M4Ovbwc/qmMpHd6FvMrh8MUAhV0CEb 8HPxMHURhT2ItN0jAqmWXO/B2XrUmqQSFIHI7ZM4fDUqubOMpSXfldBk9/tjNSb5ps7EkK3mXDn 9aGAarvbfJ+660sywefLaT40= X-Received: by 2002:a63:5522:: with SMTP id j34mr2912407pgb.148.1623814961486; Tue, 15 Jun 2021 20:42:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2+v3FSseRiKxOJ9iEyB3/L0PbIVP02C+KRkBzclARECLMSaKXTniUz8QzaCHJf1d/L9s9J3MW8hGNVbt0Yq4= X-Received: by 2002:a63:5522:: with SMTP id j34mr2912387pgb.148.1623814961186; Tue, 15 Jun 2021 20:42:41 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Jason Merrill Date: Tue, 15 Jun 2021 23:42:46 -0400 Message-ID: Subject: Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog To: Martin Sebor Cc: Hans-Peter Nilsson , Jakub Jelinek , gcc Mailing List , Jonathan Wakely X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 03:42:47 -0000 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? Jason