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

Previous Next

Package: emacs;

Reported by: Damien Cassou <damien <at> cassou.me>

Date: Fri, 14 Jun 2019 16:48:01 UTC

Severity: wishlist

Found in version 26.2.50

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Damien Cassou <damien <at> cassou.me>
Cc: 36208 <at> debbugs.gnu.org
Subject: 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).





This bug report was last modified 5 years and 347 days ago.

Previous Next


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