Commit messages and the move to git

[Segher Boessenkool]

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.

> >> - 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" :-)

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

> >> 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