This is the mail archive of the
mailing list for the GCC project.
Re: Commit messages and the move to git
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Jason Merrill <jason at redhat dot com>, Eric Raymond <esr at thyrsus dot com>, Jeff Law <law at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 2 Dec 2019 17:47:08 +0000
- Subject: Re: Commit messages and the move to git
- References: <firstname.lastname@example.org> <20191118185328.GJ16031@gate.crashing.org> <email@example.com> <20191118194450.GL16031@gate.crashing.org> <CADzB+2mL-e8J3yTVcuT2yn0ZgHu_KHjRqqXE-nJ4sVODyYi8+A@mail.gmail.com> <firstname.lastname@example.org> <CADzB+2nPi_Vt-72D_TDzuqN86+HE9ANsMbhMsOkCWRSVWHdjVA@mail.gmail.com> <email@example.com> <20191202153536.GC24609@gate.crashing.org> <firstname.lastname@example.org> <20191202172501.GD24609@gate.crashing.org>
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!