where is PRnnnn required again?

[Jonathan Wakely]

On Wed, 7 Jul 2021, 17:39 Martin Sebor, <msebor@gmail.com> wrote:

> On 7/6/21 4:09 PM, Jonathan Wakely wrote:
> >
> >
> > On Tue, 6 Jul 2021, 22:45 Martin Sebor via Gcc, <gcc@gcc.gnu.org
> > <mailto:gcc@gcc.gnu.org>> wrote:
> >
> >     On 7/6/21 3:36 PM, Marek Polacek wrote:
> >      > On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc
> wrote:
> >      >> I came away from the recent discussion of ChangeLogs requirements
> >      >> with the impression that the PRnnnn bit should be in the subject
> >      >> (first) line and also above the ChangeLog part but doesn't need
> >      >> to be repeated again in the ChangeLog entries.  But my commit
> >      >> below was rejected last Friday with the subsequent error.  Adding
> >      >> PR middle-end/98871 to the ChangeLog entry let me push the
> change:
> >      >>
> >      >> https://gcc.gnu.org/g:6feb628a706e86eb3f303aff388c74bdb29e7381
> >      >>
> >      >> I just had the same error happen now, again with what seems like
> >      >> a valid commit message.  Did I misunderstand something or has
> >      >> something changed recently?
> >      >>
> >      >> Martin
> >      >>
> >      >> commit 8a6d08bb49c2b9585c2a2adbb3121f6d9347b780 (HEAD -> master)
> >      >> Author: Martin Sebor <msebor@redhat.com <mailto:
> msebor@redhat.com>>
> >      >> Date:   Fri Jul 2 16:16:31 2021 -0600
> >      >>
> >      >>      Improve warning suppression for inlined functions [PR98512].
> >      >>
> >      >>      Resolves:
> >      >>      PR middle-end/98871 - Cannot silence -Wmaybe-uninitialized
> at
> >      >> declaration si
> >      >> te
> >      >>      PR middle-end/98512 - #pragma GCC diagnostic ignored
> >     ineffective in
> >      >> conjunct
> >      >> ion with alias attribute
> >      >
> >      > This should be just
> >      >
> >      >       PR middle-end/98871
> >      >       PR middle-end/98512
> >      >
> >      > , no?
> >
> >     Does it matter if there's text after the PR ...?
> >
> >
> >
> > Yes. With extra text the whole line is just treated as arbitrary text,
> > not a "PR component/nnnn" string. So with the extra text it won't be
> > added to the ChangeLog file, and won't match the PR in the subject line.
> >
> >        I managed to push
> >
> >     https://gcc.gnu.org/pipermail/gcc-cvs/2021-July/350316.html
> >
> >     that uses the same style earlier today
> >
> >
> > But will it add the PR numbers to the ChangeLog? I think the answer is
> > no (in which case you could edit the ChangeLog tomorrow if you want them
> > to be in there).
>
> It updated Bugzilla but it didn't add the PR numbers to the ChangeLog
> entries.  I still don't (obviously) understand the rules the hook uses
> for what to update or the rationale for them.  It seems as though
> the PR in the subject is used to update only Bugzilla but not also
> update the ChangeLogs (why not?)


Because they are two completely separate processes. Verifying the commit
message format is done by a git hook, and you can run exactly the same
checks locally before pushing a commit.

Updating bugzilla is done by a separate and different process, which has
been in place for years (decades?) before we switched to git.


The PR component/nnnn part that's
> supposed to come before the ChangeLog is used to update ChangeLog
> entries but seems to be ignored if it's followed by any text (why?)
>

See Jakub's reply.


>