GNU bug report logs - #41276
[PATCH 0/9] Various small improvements to EasyPG

Previous Next

Package: emacs;

Reported by: Jonas Bernoulli <jonas <at> bernoul.li>

Date: Thu, 14 May 2020 19:14:07 UTC

Severity: normal

Tags: patch

Merged with 41268, 41269, 41270, 41271, 41272, 41273, 41274, 41275, 41277

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #80 received at 41276 <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41276 <at> debbugs.gnu.org
Subject: Re: bug#41276: Acknowledgement ([PATCH 0/9] Various small
 improvements to EasyPG)
Date: Fri, 15 May 2020 18:56:06 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Jonas Bernoulli <jonas <at> bernoul.li>
>> Cc: 41276 <at> debbugs.gnu.org
>> Date: Fri, 15 May 2020 13:27:10 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> > A few of the patches in the series don't have commit log messages,
>> 
>> All of the patches do have commit messages.  The mail subject field is
>> used as the commit message subject line, except that the "[PATCH n/m] "
>> has to be removed.
>
> Right, that's the header line.  I meant the part after it, which
> mentions the file(s) and the function(s) where the changes are done.

I can only see one commit that lacks a commit message body in addition
to the commit message summary line.

[I am a little confused because while I agree that I failed to follow
the conventions and need to fix that, you do talk about multiple commits
that have this particular defect while I can see only a single commit,
which might potentially have that defect.]

The subject of the respective mail is:

  [PATCH 3/9] * lisp/epg-config.el (epg-config--make-gpg-configuration): Fix indentation

So the complete commit message becomes:

  * lisp/epg-config.el (epg-config--make-gpg-configuration): Fix indentation

Which I though was allowed or even encouraged.  From CONTRIBUTE:

> - If only a single file is changed, the summary line can be the normal
>   file first line (starting with the asterisk).  Then there is no
>   individual files section.

The wording confuses me.  I have decided to interpret it like so (and if
that interpretation is correct, then I suggest that CONTRIBUTE is
updated to use this wording).

> - If only a single file is changed, then the first (and in this case
>   only) individual file entry can at the same time serve as the summary
>   line, provided that the entry fits on a single line.  In this case
>   the summary should begin with an asterisk but not end with a period.
                                              -------
                                      or on the contrary "and"

I added that last sentence because there is some ambiguity that needs to
be resolved, namely:

> - Start with a single unindented summary line explaining the change;
>   do not end this line with a period. [...]

> - Some commenting rules in the GNU coding standards also apply
>   to ChangeLog entries: they must be in English, and be complete
>   sentences starting with a capital and ending with a period (except
>   the summary line should not end in a period).

However I feel it would make more sense for the first rule to override
the second.  From recent commits it looks like you and some others seem
to agree with me:

,----
| ; * src/xdisp.c: Improve the introductory commentary.
`----

but Stefan does not:

,----
| * lisp/emacs-lisp/pcase.el (pcase--fgrep): Look inside vectors
`----




This bug report was last modified 4 years and 292 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.