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

[Martin Sebor]

On 6/10/21 11:30 AM, Jakub Jelinek wrote:
> On Thu, Jun 10, 2021 at 11:20:26AM -0600, Martin Sebor wrote:
>> One other note: you mention policy above, which suggests a requirement.
>> My understanding is that the format of a commit message is a convention
>> put in place to take some of the tedium out of creating ChangeLog
>> entries.  If that's still correct, I would be more in favor of making
>> the Git commit hook smarter and more forgiving than of adding new
>> requirements imposing a more rigid format.
> 
> It is a requirement (perhaps badly worded) which has been there since
> January last year.  And it is a good idea that the PR number if any
> and some category shows up in git shortlog listing too.

Sure, but a preference for the output from a tool doesn't have to
translate into a rigid requirement on human input into another,
making it more onerous than it needs to be.

> 
>> Recognizing a PRnnnnn anywhere within the commit message and "doing
>> the thing" rather than rejecting a commit if it doesn't have a PRnnnn
>> on the first line (but does somewhere else) would be a change I'd vote
>> for.
> 
> The text above the by the script recognized ChangeLog entry, except for
> the first line which is treated by git specially, is free text, it could
> mention various PRs but doesn't actually mean that they were fixed, just
> perhaps in some way related etc.  Furthermore, for commits that fixed
> PRs we want those PR numbers be in the ChangeLog files too.

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).

Martin