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 0C6C83857813 for ; Fri, 18 Jun 2021 11:40:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0C6C83857813 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-524-rnPb2cQdMl-wJFu6zXThBA-1; Fri, 18 Jun 2021 07:40:32 -0400 X-MC-Unique: rnPb2cQdMl-wJFu6zXThBA-1 Received: by mail-wr1-f69.google.com with SMTP id b3-20020a05600018a3b029011a84f85e1cso111511wri.10 for ; Fri, 18 Jun 2021 04:40:32 -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=vgtzJ4pG8uSelK/g9JQWxtRmNu1sVcH7sW4Ep0P6OIg=; b=gryDYMOcRfVMDoTrDLcdBTLVGUHy2aO48Tm08dao2S9F+awI+4Zj8S85uAY4riZ8w+ jjr0Agkv0kQXl9dhybOaBWiLBUnX4tjbW99nEQbbWjfAtzeX3+7Venfv3PsQv6Et6YlB LKjOsXwr6NLbfbWYPE59gAC9rTk+WI4h9lR0n/nodj/VCWZjm4On7pKmvvpg7pAg3Tc7 andf+pywE5k4qJYHHt68tMSJ1wSHvt35/I5kWBWr59dPAwAN9bTBERqZMQ4S8ZtDY21T ACZZylzgzOMqZEpGxGspUAjcyAzyPIrCH++xj/W7D6zzxZQgbjljQtRB09GobZGOWfwZ yhSQ== X-Gm-Message-State: AOAM532CRjrSlv8oUDViaD117afR7p7+LExoI/kiMtVKGxXBuhw4hK1j nrUOrnVEpPE4Vn0Z4ZiI5If/ftdS2zLiCIGlIEsKxXJ9UWdgHXnb5vrunMypvH3HKx7m9Vh7cZ4 HYQEw+5m9TZFdtPYqOxG95NA= X-Received: by 2002:a05:600c:4105:: with SMTP id j5mr10893500wmi.58.1624016431516; Fri, 18 Jun 2021 04:40:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCm+PDbDrF4nOaJdet8AK12JXYvmhYO5XoTlgCO6qb4VYCtlD+f0JS8WeHwiAJ7amm664AWe+klNHAW0O8hRQ= X-Received: by 2002:a05:600c:4105:: with SMTP id j5mr10893481wmi.58.1624016431262; Fri, 18 Jun 2021 04:40:31 -0700 (PDT) MIME-Version: 1.0 References: <71b4a023-efb2-6c6a-9ced-93cce7c96540@gmail.com> <013d6727-4008-b4b5-b793-c782a5ba8e10@redhat.com> <916af0f3-0877-e977-6b6c-899edec8e706@foss.arm.com> <20210617172129.GH7746@tucnak> <16f70de7-8324-e249-dbd8-605022066d12@foss.arm.com> <070f57d5-1496-50f4-1144-3ff2e75a4460@codesourcery.com> <3eaccd30-3c1d-8f62-6382-e3ceb1b4bad2@codesourcery.com> In-Reply-To: <3eaccd30-3c1d-8f62-6382-e3ceb1b4bad2@codesourcery.com> From: Jonathan Wakely Date: Fri, 18 Jun 2021 12:40:20 +0100 Message-ID: Subject: Re: [Patch] contrib/mklog.py: Improve PR handling (was: git gcc-commit-mklog doesn't extract PR number to ChangeLog) To: Tobias Burnus Cc: Richard Earnshaw , Jakub Jelinek , Joseph Myers , =?UTF-8?Q?Martin_Li=C5=A1ka?= , gcc Mailing List X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Fri, 18 Jun 2021 11:40:36 -0000 On Fri, 18 Jun 2021 at 12:26, Tobias Burnus wrote: > > On 18.06.21 13:10, Jonathan Wakely wrote: > > > On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote: > >> PR c++/12394 - internal compiler error: in write_type, at cp/mangle.c:1517 > >> PR fortran/100123 - -ftree-fre gives incorrect result in subroutine with array declared as length 1 > >> PR c++/12394 > >> PR fortran/100123 > > Now that we put these PR cmpt/nnnn lines before the xxx/ChangeLog > > entries, is there any reason to indent them with a TAB? > > My understanding with the PR before vs. after the xxx/ChangeLog is > that if you put them before, they apply to all changelog entries > and if you put them afterward, it only only applies to the those > ChangeLog files for which they have been mentioned. That's my understanding too. > (But I also might have misread the code/were misguided by the > var names.) > > And when manually creating the changelog from scratch, they still > often end up after the ChangeLog line. > > But otherwise, I am not attached to the tab. Just one thing: > It might be slightly inconsistent to require the tab after the > xxx/ChangeLog line but not before that line. And I think a > tab should be used after the xxx/ChangeLog line. I agree it should be used after the xxx/ChangeLog line, but I am OK with the inconsistency. *Everything* after the xxx/ChangeLog line (except the next yyy/ChangeLog line) is indented. The current output of mklog.py just looks weird: PR cmpt/123456 xxx/ChangeLog: * file.c (func): Description. The changelog entry is indented because that's what the actual ChangeLog files use, but also because it makes it distinct from the "xxx/ChangeLog" heading before it. But there is no "heading" line before the PR number that it needs to stand out from. The PR line just seems to be floating in the middle of the page, looking a bit lost. I think what matters is that the script that generates the ChangeLog files can identify the "PR cmpt/123456" part and add it to the ChangeLog file. If it can identify that without a leading TAB (and insert one for the text added to the ChangeLog file) then I think we shouldn't require the TAB. And if it can still identify it even with text following the PR number, then I think we should be allowed to have text following the PR number. > PS: My feeling is that you like the proposed mklog patch :-) Yes, I think it's a nice improvement, sorry for not saying that explicitly.