On 6/10/21 3:28 PM, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 03:16:43PM -0600, Martin Sebor wrote:
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.
You keep the direction wrong. What will be rejected is [PR123456]
in the first line and no PR in the ChangeLog. People make this mistake
often.
Ah! I did say I found the terminology confusing! Thanks for
explaining it!
That isn't something the script can easily add, first of all, the component
is missing, the script would need to query bugzilla to find that out.
And, it should be user's choice where exactly in the ChangeLog the PR goes,
if it goes into every ChangeLog file, or e.g. just one etc., and that
depends on where exactly the user specified it.
I have a script that does that (looks up the component in Bugzilla
and puts PR component/nnnnn in each ChangeLog entry). I used it
until Martin wrote mklog.py.
I still think it would be preferable to make mklog.py do the work
at least in the common case(*) since, as you say, people make
the mistake often, but it doesn't seem as bad as if it had been
the other way around.
By the common case I mean a single PR nnnn in the description as
in the commit that led up to this discussion. The use case of
putting the PR nnnn in some entries and not others doesn't seem
important enough to me to worry about. Such changes should
arguably be committed separately.
Martin
Jakub
