Re: Commit messages and the move to git

["Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>]

On 02/12/2019 17:25, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 04:18:59PM +0000, Richard Earnshaw (lists) wrote:
>> On 02/12/2019 15:35, Segher Boessenkool wrote:
>>> On Mon, Dec 02, 2019 at 10:54:17AM +0000, Richard Earnshaw (lists) wrote:
>>>>   - author attributions are sometimes incorrect - reported
>>>
>>> This would disqualify that "conversion", for me at least.  Keeping all
>>> warts we had in SVN is better than adding new lies, lies about important
>>> matters even.
>> Indeed, but it's easy to turn off the option that tries to do this, if
>> it can't be made to work correctly.  We'd then be back with the existing
>> 'author == committer' situation.
> 
> But we need to be *sure* this is done correctly.  The only safe thing
> to do is to turn off all such options, if we cannot trust them.

Of course.  But that's a decision that can be made quite late, because
we know we *can* turn them off if we want to.

> 
>>>> - certain key words in otherwise not very useful summary lines are
>>>>   also spotted and used to add [revert] or [backport] annotations to
>>>>   the summary.
>>>
>>> You won't see tags like that from anyone who uses the normal git commit
>>> flows: the piece of the mail subject between [] is deleted.
>>
>> Well, true if you use "git am" without the -k or -b options; false
>> otherwise.  We have plenty of existing patches in the repo that have
>> tags like this, though it doesn't appear to be the 'git way' I grant you.
> 
> Yes, "the normal commit flows" :-)
> 

Well my normal commit flow these days is to use -b, because that only
removes "[PATCH...]" annotations.

Nevertheless, we will most likely keep any existing "[...]" tags.

>> We could extend the script to rewrite all [tag] attributions in tag:
>> form, but I'm not really sure it's worth it.
> 
> Sure; I'm just saying rewriting old commit messages in such a style that
> they keep standing out from new ones is a bit of a weird choice.
> 

One of the advantages of doing this in a script is that we have exactly
three places in the script to change, and that's a trivial operation to
do.  Tweaking the logic overall is much harder as it can have surprising
effects at times.

>>>> No changes are made to the main commit log, if we add a new summary 
>>>> line, the entire original text is kept.
>>>
>>> That is good (an important requirement even).
>>
>> Yes, I even steer clear of trimming blank lines at the head or tail of
>> the message, but it's possible that reposurgeon might do that itself later.
> 
>> The real question at this point is whether or not these commit summaries
>> are better than the existing ones.  Personally, I think they are (or I
>> wouldn't have spent the time working on this), but I'm not the only
>> person with an interest here...
> 
> Thanks for the effort, regardless of the outcome!
> 
> 
> Segher
> 

R.