From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id E4BE93836023 for ; Thu, 10 Jun 2021 21:56:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E4BE93836023 Received: by mail-ot1-x32d.google.com with SMTP id 6-20020a9d07860000b02903e83bf8f8fcso1169842oto.12 for ; Thu, 10 Jun 2021 14:56:38 -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=KjK+22FcLztYMz1ThGanMSzoe9MfyrnkKiN9IrrTqRs=; b=ru0lhYLobSbwrQwAftvv3P1P4jUxGK1cJ9+GoyR/DChw5vqvEgMUoLEyHK1xHxkm4Q zfJ8Xd3R7uGWKA7wgKLRWxCboEXtc7a7bLRCpSUHnF+tVGSPVR2fZt5UE+eIVzIG8TOQ ZirtyPIWMgD7Uq9ENw7lHV1ecs2oS6PHDEZi0oJA+3U9AEMUa29WCksho7xwPXOlEqcK H4fFz2c0qB7BNnybgFnKtvbdp9LNiEJhaDNho6UtUC48ObwbwytCS1gTDKGUVi2yanR/ WHFC3mvZqrb06e2uDFHJZbkFgmjr6eRzF8CcjPtm71+yxWozRXZoWZh7wYUneshzN4jL YMcA== X-Gm-Message-State: AOAM532jfeGenVZAZJHk8yTg9Ghvb4PypD4XA3enLNeqPlk6HbDg6unV u7/06SHw9UionyXELsiPR/QWDby/J2I= X-Google-Smtp-Source: ABdhPJxF+b9RCFvy89lHnxuV+n5k38EJLpWdsrSkzMTlImraZ7iakVKVfbmZN7qLOXn7NLMi25Ktxg== X-Received: by 2002:a05:6830:2382:: with SMTP id l2mr395409ots.105.1623362198166; Thu, 10 Jun 2021 14:56:38 -0700 (PDT) Received: from [192.168.0.41] (97-118-122-241.hlrn.qwest.net. [97.118.122.241]) by smtp.gmail.com with ESMTPSA id u15sm779746ooq.24.2021.06.10.14.56.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Jun 2021 14:56:37 -0700 (PDT) Subject: Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog To: Jakub Jelinek Cc: Jonathan Wakely , 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> <20210610212834.GL7746@tucnak> From: Martin Sebor Message-ID: Date: Thu, 10 Jun 2021 15:56:36 -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: <20210610212834.GL7746@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.6 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: Thu, 10 Jun 2021 21:56:40 -0000 On 6/10/21 3:28 PM, Jakub Jelinek wrote: > On Thu, Jun 10, 2021 at 03:16:43PM -0600, Martin Sebor wrote: >>> Just look at the start of this thread. Some people put >>> the [PRnnnnn] only in the first line of the commit. And that is >>> what these changes want to diagnose, that is an error and results >>> in bugzilla not being updated. >> >> That's Tobias' proposal, yes: >> >> One options would be to require a 'PR /' line if there >> is 'PRnnnnn+' in the commit title, rejecting the commit otherwise. >> >> I can't think of why rejecting such commits is preferable to having >> the script fix them up by copying the PRnnnn strings from the ChangeLog >> entries in the commit message into the first line. So that's my >> counterproposal: make the script do the tedious work for us. > > You keep the direction wrong. What will be rejected is [PR123456] > in the first line and no PR in the ChangeLog. People make this mistake > often. Ah! I did say I found the terminology confusing! Thanks for explaining it! > That isn't something the script can easily add, first of all, the component > is missing, the script would need to query bugzilla to find that out. > And, it should be user's choice where exactly in the ChangeLog the PR goes, > if it goes into every ChangeLog file, or e.g. just one etc., and that > depends on where exactly the user specified it. I have a script that does that (looks up the component in Bugzilla and puts PR component/nnnnn in each ChangeLog entry). I used it until Martin wrote mklog.py. I still think it would be preferable to make mklog.py do the work at least in the common case(*) since, as you say, people make the mistake often, but it doesn't seem as bad as if it had been the other way around. By the common case I mean a single PR nnnn in the description as in the commit that led up to this discussion. The use case of putting the PR nnnn in some entries and not others doesn't seem important enough to me to worry about. Such changes should arguably be committed separately. Martin > > Jakub >