public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>,
	Gerald Pfeifer <gerald@pfeifer.com>
Cc: gcc@gcc.gnu.org
Subject: Re: More consistency for Git log messages?
Date: Wed, 30 Dec 2020 14:34:57 -0700	[thread overview]
Message-ID: <58169830-3f6c-eea8-dd6a-734917882271@gmail.com> (raw)
In-Reply-To: <CAH6eHdTgbY9TKXNSFYHvpKNDCBFa0wrsnRXDQn-uxTixb686yw@mail.gmail.com>

On 12/29/20 1:49 AM, Jonathan Wakely via Gcc wrote:
> On Mon, 28 Dec 2020, 23:55 Gerald Pfeifer, <gerald@pfeifer.com> wrote:
> 
>> Having spent a bit more time with GCC sources (as opposed to wwwdocs)
>> recently and looking for prior art to guide me, I noticed there's a
>> lot of options to specific the ChangeLog file(s) to use.
>>
>> And correspondingly a lot of inconsistency.
>>
>> Right now we seem to allow for
>>
>>   1. gcc/cp/ChangeLog
>>   2. gcc/cp/ChangeLog:
>>   3. gcc/cp
>>   4. gcc/cp:
>>   5. gcc/cp/
>>
>> and probably more.
>>
> 
> We also allow not specifying the directory at all, if it can be deduced
> from the changed files.

That's a nice feature I didn't even know about!

>> Can we streamline this a bit and converge on one of the forms 3-5?
>>
>> Personally I'd suggest 3 (the shortest) or 5 (the directory), but whatever
>> ... as long as things become more consistent, which is easier on newbies
>> and reading logs (or automatically processing them later on).
>>
> 
> We already process them automatically.
> 
> It's worth noting that some people generate then automatically too, and the
> mklog.py hook uses form 2 IIRC.

I believe you're right.  I use the script to generate a template
for my first patch.  For subsequent revisions I copy the template
from the first one and edit it by hand (and often mess things up,
making the commit hook complain).

I rarely read ChangeLogs so I'm not bothered by inconsistencies
in it but I can relate to those who do and are.  I'm not against
increasing the consistency of the format just as long as it
doesn't make the commit procedure more onerous.  Changing
the commit hook to massage the ChangeLog lines (and any other
minutiae) into a preferred format would do that.

Martin

  reply	other threads:[~2020-12-30 21:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-28 23:54 Gerald Pfeifer
2020-12-29  8:49 ` Jonathan Wakely
2020-12-30 21:34   ` Martin Sebor [this message]
2020-12-30 14:19 ` Segher Boessenkool
2020-12-30 14:25   ` H.J. Lu
2020-12-30 14:49 ` Jakub Jelinek
2021-01-06  8:23   ` Martin Liška

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58169830-3f6c-eea8-dd6a-734917882271@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gerald@pfeifer.com \
    --cc=jwakely.gcc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).