On 18/11/2019 15:55, Segher Boessenkool wrote:
Hi!

On Mon, Nov 18, 2019 at 03:32:06PM +0000, Richard Earnshaw (lists) wrote:
I wrote this script for two reasons
    1) To learn some python (finally I had a good reason to go and do
this :)

So I am last now?  Heh.

    2) To try to improve some of our legacy commit messages, especially
where they appear in git as just the name of the author (information
that is already readily available in other components.

So for example, a commit such as this one:

2019-10-30  Richard Biener  <rguent...@suse.de>

        PR tree-optimization/92275
        * tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
        Copy all loop-closed PHIs.

        * gcc.dg/torture/pr92275.c: New testcase.


Would be matched and the line

    PR tree-optimization/92275 ICE: error: definition in block 11 does
not dominate use in block 15 since r277566

added as a summary

That immediately shows some of the shortcomings of this approach: the
subject line is much too long, but more importantly, it doesn't make
much sense: it is not what the patch does, it is the description of a
bug that is related in some way to this patch.  It is not uncommon for
a commit to not fix the problem mentioned in the bug report (if it *is*
a problem!), or not fix it completely.

Then again, changing all such subject lines to read "patch" could also
already be considered an improvement.


Well the real question is whether such a summary is worse than the current situation of just printing the author in the wrong field. I personally don't think it is. As for the over-long lines, truncating them is trivial, if that would be better. It's also easy to drop the component field. I put it in for now as it helps with verifying those commits that look a bit suspicious (I put even more info in for now in that case, but would not expect that in a final conversion).

There are about 560 commits where the code highlights that the data might be suspect (usually a category mismatch). I'd like to audit those if we are to go ahead with this; but I don't want to waste time on that if nobody wants this information as a careful audit will take quite a lot of effort. I've already spotted over 40 commits where the PR was incorrect and included fixed PRs for those commits.

R.

Reply via email to