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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 52ADF385802E for ; Wed, 16 Jun 2021 20:49:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52ADF385802E Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-140-4C9NnofQN4ynbsKH8-tuzQ-1; Wed, 16 Jun 2021 16:49:54 -0400 X-MC-Unique: 4C9NnofQN4ynbsKH8-tuzQ-1 Received: by mail-qk1-f199.google.com with SMTP id r190-20020a375dc70000b02903acea04c19fso522987qkb.8 for ; Wed, 16 Jun 2021 13:49:54 -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:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=l2YQKC2/iNAkIIhD1LDimR2v7a7O7oN0RN48ORZ3N1A=; b=trujXos4tC+WJZScKIEjhM8yXqhtU1ostzOkBeg6LY6x6kGuj4er4gNtVsuylTCkL9 QohQH7DZUnH4G8YeGl4t1ME7llcRDN2qLL11drjmCiPXu/CatR4wzHhPMMx+sUUDyQnF WllrV3GjpdcUG5ibnE6FKltloR3MIQKT9Y7VgoPkduUWEiku/vrLI6/vuMJ5GbX0xuYF F43yItHNElOprmF4pmOwLyFuveAt4W0Era//5bfthCKh572ui6wZrQ0IQnu1b8kWpFPY HgTZpvbN/yzaLu8l/tJOcvvQbG0ZDZ7AEvf9KxuOxGV+PZ56rFOLIjyOruCPiXJW0p3h 2nKg== X-Gm-Message-State: AOAM53076Qbk6F2yb3zxzEEwTitOlkkvnOwdxfULUZynG5syksqee3zd cmiWfFOrXFspxBeHDhR7BCNOlxrPqS6zxKgfyhGHs5yXABPoc4VTMQjqKQklxJpl7oMYNcnKvyU rw7lLcHc= X-Received: by 2002:a05:6214:c6b:: with SMTP id t11mr2016375qvj.31.1623876593700; Wed, 16 Jun 2021 13:49:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxkplAKm7E2+XwRiL4tvo+VReR1dA9nkmt+q7wi2VaZEFFW2PnFR9ugYIS3Xac4uzWT5VHZ/g== X-Received: by 2002:a05:6214:c6b:: with SMTP id t11mr2016359qvj.31.1623876593476; Wed, 16 Jun 2021 13:49:53 -0700 (PDT) Received: from [192.168.1.148] (130-44-159-43.s11817.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id b7sm1670913qti.21.2021.06.16.13.49.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 13:49:52 -0700 (PDT) Subject: Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog From: Jason Merrill To: Martin Sebor 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> Message-ID: Date: Wed, 16 Jun 2021 16:49:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------429889FB46DAD78A5EA66F44" Content-Language: en-US X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, 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 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 20:49:59 -0000 This is a multi-part message in MIME format. --------------429889FB46DAD78A5EA66F44 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: --------------429889FB46DAD78A5EA66F44 Content-Type: text/x-patch; charset=UTF-8; name="0001-mklog-add-subject-line-skeleton.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-mklog-add-subject-line-skeleton.patch" >From a4e1c5eef3491e3d2e72a01e864af204f124a994 Mon Sep 17 00:00:00 2001 From: Jason Merrill Date: Wed, 16 Jun 2021 16:46:38 -0400 Subject: [PATCH] mklog: add subject line skeleton To: gcc-patches@gcc.gnu.org contrib/ChangeLog: * mklog.py: Add an initial component: [PRnnnnn] line when we have a PR. --- contrib/mklog.py | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/contrib/mklog.py b/contrib/mklog.py index 5c93c707128..6113ae30a8e 100755 --- a/contrib/mklog.py +++ b/contrib/mklog.py @@ -39,6 +39,7 @@ import requests from unidiff import PatchSet pr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PPR [a-z+-]+\/[0-9]+)') +prnum_regex = re.compile(r'PR (?P[a-z+-]+)/(?P[0-9]+)') dr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PDR [0-9]+)') dg_regex = re.compile(r'{\s+dg-(error|warning)') identifier_regex = re.compile(r'^([a-zA-Z0-9_#].*)') @@ -67,6 +68,7 @@ PATCH must be generated using diff(1)'s -up or -cp options script_folder = os.path.realpath(__file__) root = os.path.dirname(os.path.dirname(script_folder)) +firstpr = '' def find_changelog(path): folder = os.path.split(path)[0] @@ -134,6 +136,7 @@ def generate_changelog(data, no_functions=False, fill_pr_titles=False): prs = [] out = '' diff = PatchSet(data) + global firstpr; for file in diff: # skip files that can't be parsed @@ -166,6 +169,9 @@ def generate_changelog(data, no_functions=False, fill_pr_titles=False): # Found dg-warning/dg-error line break + if prs: + firstpr = prs[0] + if fill_pr_titles: out += get_pr_titles(prs) @@ -308,8 +314,14 @@ if __name__ == '__main__': start = list(takewhile(lambda l: not l.startswith('#'), lines)) end = lines[len(start):] with open(args.changelog, 'w') as f: + if (not start) or (start[0] == ''): + # initial commit subject line 'component: [PRnnnnn]' + m = prnum_regex.match(firstpr) + if m: + start.insert (0, m.group('comp') + ': [PR' + + m.group('num') + ']') if start: - # appent empty line + # append empty line if start[-1] != '': start.append('') else: -- 2.27.0 --------------429889FB46DAD78A5EA66F44--