This is the mail archive of the
mailing list for the glibc project.
Re: Automating the maintenance of the ChangeLog file
* Tulio Magno Quites Machado Filho:
> J William Piggott <firstname.lastname@example.org> writes:
>> On Tue, 27 Nov 2018, Zack Weinberg wrote:
>>> On Tue, Nov 27, 2018 at 2:29 AM Florian Weimer <email@example.com> wrote:
>>>> * Zack Weinberg:
>>>>> Specifically, I propose: Effective immediately, project policy
>>>>> requires the Git commit message for each commit to end with the full
>>>>> text of a traditional ChangeLog entry for that commit.
>>>> How can I see what is part of the proposed commit (message) and what is
>>>> not during patch review?
>>> If we take `git format-patch` as a baseline, that means the subject
>>> line is the first line of the commit message, and everything in the
>>> email body up to the first line of the actual diff is the commit
>>> message. But sometimes one wants to say things in the email that
>>> aren't going to go into the commit message. I don't have a good
>>> suggestion for how to handle that, ...
>> Git already has a way to do that. The submitter can write anything they want to
>> between the '---' and 'diff ...'
>> That is '---' ends the commit message.
> Git also supports scissors (from git-mailinfo(1)):
> Remove everything in body before a scissors line. A line
> that mainly consists of scissors (either ">8" or "8<") and
> perforation (dash "-") marks is called a scissors line, and
> is used to request the reader to cut the message at that
> line. If such a line appears in the body of the message
> before the patch, everything before it (including the
> scissors line itself) is ignored when this option is used.
> This is useful if you want to begin your message in a
> discussion thread with comments and suggestions on the
> message you are responding to, and to conclude it with a
> patch submission, separating the discussion and the
> beginning of the proposed commit log message with a scissors line.
> This can be enabled by default with the configuration
> option mailinfo.scissors.
> git am also supports this.
Does our Patchwork instance support this? Are there Gnus/mutt
extensions to highlight the relevant parts of a patch submission?
I want to make sure that both patch authors and reviewers can tell with
high confidence what is proposed for committing. If we want to generate
ChangeLogs from commit message contents, I think we need to increase the
quality of commit messages.
Does GNU offer hosting for a development workflow which is closer to the
pull request model?