GNU bug report logs - #36208
26.2.50; Add tooling for commit message format checking

Previous Next

To reply to this bug, email your comments to 36208 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Damien Cassou <damien <at> cassou.me>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.2.50; Add tooling for commit message format checking
Date: Fri, 14 Jun 2019 18:47:29 +0200

Hi



writing commit messages that comply with Emacs' guidelines requires a
good understanding of many details described in CONTRIBUTE.  To reduce
the workload of new contributors and of reviewers, part of these
guidelines could be transformed into tools.

Here are some of the checks that humans have to do these days:

1. dots after every sentence (even just "New function" must terminate
   with a dot)
2. double-space after dots ending sentences
3. no indentation (M-q adds 2 spaces which we don't want)
4. line length
5. the Copyright-paperwork-exempt token
6. every single change is documented
7. no colon if another function of the same file has the same comment

I can imagine several tools:

- a major mode for editing commit messages:

  - for check 2., sentence-end-double-space could be set to t

  - for check 3., I guess another variable could be set

  - for check 4., setting fill-column

  - for check 5., a shortcut could help adding such tokens

  - for check 6., a shortcut (beyond `C' which triggers
    `magit-commit-add-log-insert') could add a template with all the
    changes

- a flymake backend to mark problems:

  - for checks 1., 3., 4., and 7., I believe it's obvious

  - for check 2., words ending with a dot and just one space (with a
    whitelist to avoid false positives such as "etc."  and "aka.")

- a patch checker (e.g., `./check_patch.sh *.patch`):

  - could check the same as the flymake backend and also checks 5 and 6.

Best,

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

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

From: Alan Mackenzie <acm <at> muc.de>
To: Damien Cassou <damien <at> cassou.me>
Cc: 36208 <at> debbugs.gnu.org
Subject: Re: bug#36208: 26.2.50; Add tooling for commit message format checking
Date: 17 Jun 2019 07:39:32 -0000

Hello, Damien.

In article <mailman.90.1560530885.10840.bug-gnu-emacs <at> gnu.org> you wrote:
> Hi

> writing commit messages that comply with Emacs' guidelines requires a
> good understanding of many details described in CONTRIBUTE.  To reduce
> the workload of new contributors and of reviewers, part of these
> guidelines could be transformed into tools.

It's worth pointing out that C-x 4 a
(add-change-log-entry-other-window), from the days when we used to
write ChangeLog entries, does some of what you're asking for.  Maybe
this could be adapted.

> Here are some of the checks that humans have to do these days:

> 1. dots after every sentence (even just "New function" must terminate
>    with a dot)
> 2. double-space after dots ending sentences
> 3. no indentation (M-q adds 2 spaces which we don't want)
> 4. line length
> 5. the Copyright-paperwork-exempt token
> 6. every single change is documented
> 7. no colon if another function of the same file has the same comment

What we are really missing is an ability to edit commit messages after
committing with a faulty message.  This is a deficiency of git.

> I can imagine several tools:

> - a major mode for editing commit messages:

>   - for check 2., sentence-end-double-space could be set to t

>   - for check 3., I guess another variable could be set

>   - for check 4., setting fill-column

>   - for check 5., a shortcut could help adding such tokens

>   - for check 6., a shortcut (beyond `C' which triggers
>     `magit-commit-add-log-insert') could add a template with all the
>     changes

> - a flymake backend to mark problems:

>   - for checks 1., 3., 4., and 7., I believe it's obvious

>   - for check 2., words ending with a dot and just one space (with a
>     whitelist to avoid false positives such as "etc."  and "aka.")

> - a patch checker (e.g., `./check_patch.sh *.patch`):

>   - could check the same as the flymake backend and also checks 5 and 6.

> Best,

> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st

> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Damien Cassou <damien <at> cassou.me>, 36208 <at> debbugs.gnu.org
Subject: Re: bug#36208: 26.2.50; Add tooling for commit message format checking
Date: Mon, 17 Jun 2019 09:46:17 +0200

> What we are really missing is an ability to edit commit messages after
> committing with a faulty message.  This is a deficiency of git.

We can add information with git notes, though I think we're not using
that capability.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Damien Cassou <damien <at> cassou.me>, Alan Mackenzie <acm <at> muc.de>,
 36208 <at> debbugs.gnu.org
Subject: Re: bug#36208: 26.2.50; Add tooling for commit message format checking
Date: Mon, 17 Jun 2019 11:10:22 -0400

Juanma Barranquero <lekktu <at> gmail.com> writes:

>> What we are really missing is an ability to edit commit messages after
>> committing with a faulty message.  This is a deficiency of git.
>
> We can add information with git notes, though I think we're not using
> that capability.

Last time I checked this out, having many note refs in the git
repository would noticeably slow down all git operations.

https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg01184.html

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Damien Cassou <damien <at> cassou.me>
Cc: 36208 <at> debbugs.gnu.org
Subject: Re: bug#36208: 26.2.50; Add tooling for commit message format checking
Date: Thu, 04 Jul 2019 22:02:28 -0400

Damien Cassou <damien <at> cassou.me> writes:

> 1. dots after every sentence (even just "New function" must terminate
>    with a dot)
> 2. double-space after dots ending sentences

>   - for check 6., a shortcut (beyond `C' which triggers
>     `magit-commit-add-log-insert') could add a template with all the
>     changes

I've started work on a command which can generate the ChangeLog
skeleton, see https://debbugs.gnu.org/16301#11.  While doing that, I
found that we already have log-edit-mode (and derived mode
vc-git-log-edit-mode) which already has some checking for 1 and 2 in its
font-lock rules.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Damien Cassou <damien <at> cassou.me>
Cc: 36208 <at> debbugs.gnu.org
Subject: Re: bug#36208: 26.2.50; Add tooling for commit message format checking
Date: Fri, 05 Jul 2019 17:21:16 +0100

Damien Cassou <damien <at> cassou.me> writes:

> writing commit messages that comply with Emacs' guidelines requires a
> good understanding of many details described in CONTRIBUTE.  To reduce
> the workload of new contributors and of reviewers, part of these
> guidelines could be transformed into tools.
>
> Here are some of the checks that humans have to do these days:
>
> 1. dots after every sentence (even just "New function" must terminate
>    with a dot)
> 2. double-space after dots ending sentences
> 3. no indentation (M-q adds 2 spaces which we don't want)

Are you using Magit's git-commit-mode?  If so, see PR #3911:
https://github.com/magit/magit/pull/3911

Thanks,

-- 
Basil

Previous Next

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