git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor]

On 6/10/21 1:09 PM, Jakub Jelinek wrote:
> On Thu, Jun 10, 2021 at 12:55:43PM -0600, Martin Sebor wrote:
>> Instead of rejecting commits that don't mention all the same PRs on
>> the first line of the commit as in the ChangeLog entries it seems
>> that the Git commit script could extract the PRnnnn references from
>> just the ChangeLong entries (if we wanted to constrain it that way
>> to avoid the unrelated references and append each to the end of
>> the $git_description if it isn't already there.  I thought it
>> already did that (and more).
> 
> 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 <comp>/<nnnnn+>' 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.

> The current changes won't do the other direction, i.e. if there
> is a PR line in the ChangeLog entry complain about [PRnnnnn] missing
> in the first line.  The fact that it isn't required by the script doesn't
> mean people shouldn't do it, but if they occassionally forget, it is not
> that bad as not mentioning it in ChangeLog.

I don't see why the script users should be subjected to this tedium
when it can be done in the script itself with (presumably) only
a little more effort.  The proposed change is, IMO, a step in
the wrong direction.

Martin