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

[Martin Sebor]

On 6/17/21 10:32 AM, Jonathan Wakely wrote:
> On Thu, 17 Jun 2021 at 16:33, Martin Sebor <msebor@gmail.com> wrote:
>>
>> On 6/17/21 9:11 AM, Michael Matz wrote:
>>> Hello,
>>>
>>> On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote:
>>>
>>>>> The original problem is that the PR wasn't _in the body_ of the commit
>>>>
>>>> But I see [PR100085] right there at the end of the _summary line_:
>>>
>>> Emphasis mine
> 
> Right. How are we still discussing this part of the original issue?!

Because no has explained *why* there had to be an issue to begin
with: the rationale for ignoring the piece of data that was in
the commit message and that could have been used to update Bugzilla.
I have just gone through the whole discussion again in case I missed
it but I couldn't find an answer.

>>
>> Let me make sure I understand: we ask users to put PR numbers
>> on the first line but the script doesn't consider the first line
>> a part of the "body" and so it doesn't use the PRs mentioned on
>> it to update Bugzilla?
> 
> AFAIK Bugzilla does not process a "PRnnnnn" string anywhere in the
> commit log. It only processes the full "PR component/nnnn" form. This
> is stated in the docs:
> 
> "The body of the commit message should still contain the full form (PR
> <component>/nnnnn) within the body of the commit message so that
> Bugzilla will correctly notice the commit."
> 
> We want it on the subject line for **our** benefit, not bugzilla's. So
> that the outout of 'git log --oneline' shows useful context.

But *why* do we not want to use the short PR in the subject to
update Bugzilla?

It sounds like our tooling (since r12-771) massages ChangeLogs
based on the PR component/nnnn in the commit description.  There
also is a way to determine the component for a PR nnnn by querying
Bugzilla (the -p option to mklog.py).  So why are we required to
duplicate the PR in two places in the commit message and why do
we need to provide the component?  In other words, why can
the original problem not be solved by making our tooling
smarter instead of rejecting such commits?

Martin