Commit messages and the move to git

Richard Earnshaw (lists) Richard.Earnshaw@arm.com
Thu Dec 19 11:58:00 GMT 2019


On 19/12/2019 11:50, Richard Earnshaw (lists) wrote:
> On 19/12/2019 09:27, Jonathan Wakely wrote:
>> On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> 
>> wrote:
>>>
>>> On Wed, 18 Dec 2019, Joseph Myers wrote:
>>>
>>>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
>>>>
>>>>> 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.
>>>>
>>>> Concretely, here is the current list of 664 checkme: annotations where
>>>> something was suspicious about the PR number (either component 
>>>> mismatch or
>>>> resolved as INVALID).  Would some people like to volunteer to pick up
>>>> sections of this list and, for their section, produce a list of SVN
>>>> revisions (at the end of the checkme line) for which the PR number 
>>>> appears
>>>> to be correct, and a list of mappings from SVN revision to correct PR
>>>> number when the PR number appears to be wrong?  For any that don't get
>>>> reviewed like that we can easily make the script, for the final
>>>> conversion, decline to add a new summary line for any commit where 
>>>> the PR
>>>> number is suspicious.
>>>
>>> Here's a slightly shorter version with 644 checkme: annotations, after
>>> adding a few more component aliases to the script (e.g., no longer
>>> considering it suspicious if the log message says PR g++/something and
>>> that PR is in the component that's actually called c++).
>>
>> Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
>> Line 326: lto SVN r196613, PR number is correct
>> Line 411: libstdc++ SVN r219147, PR number is correct
>>
>>
>> How do you want the mapping from SVN revision to correct PR to be 
>> expressed?
>>
>> Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 
>> 39238)
>> Line 608: lto SVN r268728 should be PR 87089 (not 87809)
>> Line 616: lto SVN r269799 should be PR 87089 (not 87809)
>>
> 
> Best of all would be a pull request on 
> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py 
> directly.
> 
> Second best would be something like
> 
> whitelist:
> 
> "<svn-revnumber>", "<svn-revnumber>",
> 
> etc, where svn-revnumber is the revision number in svn as reported in 
> the checkme above but without the leading 'r'
> 
> and
> 
> Change:
> 
>     "<svn-revnumber>": {"PR": "<correct-bugid>"},
>     ....
> 

There are two other actions that can be applied to commits, in the 
change section:

      "<svn-revnumber>" {"ignore": True},

(case is important: True, not true or TRUE), will force the script to 
ignore that commit entirely; you may end up with a pretty meaningless 
summary line, so this should be used sparingly if at all.

and

      "<svn-revnumber>" {"summary": "<new summary>"},

will use the specificed <new summary> as the summary line.

Given the number of commits, we can't rewrite everything, but if you see 
a summary that looks particularly wrong, we can insert something else 
using this override.

R.

> where svn-revnumber is as before, and <correct-bugid> is the the PR 
> number that should have been used.
> 
> The above can then be pasted quickly into the script to update it.
> 
> R.



More information about the Gcc mailing list