Commit messages and the move to git

[Richard Earnshaw (lists)]

On 18/11/2019 17:11, Segher Boessenkool wrote:
> Hi Richard,
> 
> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) wrote:
>> On 18/11/2019 15:55, Segher Boessenkool wrote:
>>> 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.
> 
> I think that non-obviously-wrong-but-still-wrong info is not something
> we should introduce.  And, I think this will happen a *lot*.
> 
> Maybe you can just put in artificial subjects like "Patch related to
> PR12345" or the like?  That is correct, displays a lot better, and is
> at least as useful (imo).
> 
>> There are about 560 commits where the code highlights that the data
>> might be suspect (usually a category mismatch).
> 
> What about commits that mention multiple PRs?  What do you do for those?
> (Are there as many of those as I think, anyway?)  With normally very short
> subjects you could put all of them in there :-)
> 

Depends on the context.  If there look to be multiple date-stamp-author 
patterns and the lines are not identical we put:

[multiple commits]

If there are more that three PRs and the word backport appears in the 
text, then it generates a 'backport' summary of the form

Backport PRs 91606, 91772, 91790, 91812, 91968

or if there are more than about 10 prs,

Backport PRs 41611, 41905, 41906, 41961, 42006, 42025, 42057, 42069, 
42078, 42084 and more

it's easy to change the thresholds.

Otherwise we just pick the first PR found.  The assumption in this case 
is that PRs are related and thus one summary is likely as good as another.

Yes, we can just print PR numbers, and we could print multiple numbers; 
but generally I find that less helpful than the summary.

Finally, note that this does *not* delete any information.  The summary 
is added in addition to the existing text rather than replacing it.

I've attached a sample from the start of the fixed list - the full list 
is far too big to post to give a flavour of how the script currently 
works.  Note that annotations of the form [checkme: ....] in the summary 
are for diagnostic purposes.  These are where heuristics suggest that 
there's a higher than normal chance that the PR number is incorrect and 
that manual auditing is recommended.  Such annotations would not be 
appropriate in the final conversion.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixed.xz
Type: application/x-xz
Size: 30136 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20191118/cd36af18/attachment.xz>