Commit messages and the move to git

[Richard Earnshaw (lists)]

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  <rguenther@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.