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

Martin Sebor msebor@gmail.com
Fri Jun 11 17:02:52 GMT 2021


On 6/11/21 3:13 AM, Jonathan Wakely wrote:
> On Thu, 10 Jun 2021 at 22:16, Martin Sebor wrote:
>> 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.
> 
> I don't see why "improve the mklog.py script to automatically follow
> the policy" is in conflict with "enforce the policy".
> 
> If the script can be improved to do the right thing automatically when
> you commit (it's not clear if it can be improved that way, but let's
> say it can) then what's the problem with enforcing it when you push
> the commit to the server? What are you being "subjected to"? If it's
> automated, what is "this tedium"? You've already followed the policy,
> why do you care if there are checks to make sure that everybody
> follows the policy, including the people not using the script and
> writing the entire commit msg by hand?
> 
> I'm not saying we are going to enforce every part of the policy
> (because the policy isn't even clear right now), but if we wanted to
> do it later, I don't understand your objection.

My objection is to making our policies and tools more restrictive
than they need to be.  We shouldn't expect everyone to study whole
manuals just to figure out how to successfully commit a change (or
learn how to format it just the right way).  It should be easy.

Setting this discussion aside for a moment and using a different
example, the commit hook rejects commit messages that don't start
ChangeLog entries with tabs.  It also rejects commit messages that
don't list all the same test files as those changed by the commit
(and probably some others as well).  That's in my view unnecessary
when the hook could just replace the leading spaces with tabs and
automatically mention all the tests.

I see this proposal as heading in the same direction.  Rather than
making the script fix things up if we get them wrong it would reject
the commit, requiring the user to massage the ChangeLog by hand into
an unnecessarily rigid format.

Martin

PS I think I referred to mklog.py when I meant gcc-commit-mklog,
confusing the discussion and probably even myself.  Sorry about
that.  The mklog.py script is great.  It helps us avoid some of
these mistakes.  But the script isn't perfect and commit messages
for some more involved changes still need to be hand-edited.
That's when the mistakes usually creep back in.  But the fact
that we need a script to preformat a commit message for us in
the stringent format that makes the commit hook happy seems like
a pretty good indication that our policies and requirements are
too onerous for most of us to get all the details right.


More information about the Gcc mailing list