bug#36208: 26.2.50; Add tooling for commit message format checking

bug#36208: 26.2.50; Add tooling for commit message format checking

[Damien Cassou]

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

bug#36208: 26.2.50; Add tooling for commit message format checking

[Alan Mackenzie]

Hello, Damien.

In article <mailman.90.1560530885.10840.bug-gnu-emacs@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).

bug#36208: 26.2.50; Add tooling for commit message format checking

[Juanma Barranquero]

> 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.

bug#36208: 26.2.50; Add tooling for commit message format checking

[Noam Postavsky]

Juanma Barranquero <lekktu@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

bug#36208: 26.2.50; Add tooling for commit message format checking

[Noam Postavsky]

Damien Cassou <damien@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.

bug#36208: 26.2.50; Add tooling for commit message format checking

[Basil L. Contovounesios]

Damien Cassou <damien@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