From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jelle Licht Subject: Re: Automatically checking commit messages Date: Thu, 21 Sep 2017 13:45:06 +0200 Message-ID: References: <9a88d837.ADkAADITH3QAAAAAAAAAAAOtZhgAAAACwQwAAAAAAAW9WABZwo2s@mailjet.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403043ef77cb8ce540559b19f7c" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duzux-00032j-IH for guix-devel@gnu.org; Thu, 21 Sep 2017 07:45:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1duzur-0007jn-En for guix-devel@gnu.org; Thu, 21 Sep 2017 07:45:19 -0400 Received: from mail.fsfe.org ([2001:aa8:ffed::3:102]:35232) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1duzur-0007gn-3x for guix-devel@gnu.org; Thu, 21 Sep 2017 07:45:13 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.fsfe.org (Postfix) with ESMTP id D7CF263BBBA for ; Thu, 21 Sep 2017 13:45:09 +0200 (CEST) Received: from mail.fsfe.org ([127.0.0.1]) by localhost (cavendish.fsfeurope.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lidyQyhlwUFd for ; Thu, 21 Sep 2017 13:45:09 +0200 (CEST) Received: by mail-ua0-f175.google.com with SMTP id t5so3430340uad.13 for ; Thu, 21 Sep 2017 04:45:09 -0700 (PDT) In-Reply-To: <9a88d837.ADkAADITH3QAAAAAAAAAAAOtZhgAAAACwQwAAAAAAAW9WABZwo2s@mailjet.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Arun Isaac Cc: guix-devel --f403043ef77cb8ce540559b19f7c Content-Type: text/plain; charset="UTF-8" 2017-09-20 17:47 GMT+02:00 Arun Isaac : > > I have been working on a guile script to automatically check commit > messages -- something like `guix lint' but for commit messages instead > of package definitions. This could help us enforce our commit message > guidelines and avoid screw-ups like the one I did in commit > 1ee879e96705e6381c056358b7f426f2cf99c1df. I believe more automation is > essential and would help us scale better if/when we have more people > with commit access. > Hear, hear. > > I have taken the following approach with my script: I have devised a > grammar (shown below) to parse commit messages. Once the parser outputs > a parse tree for the commit message, we can apply any number of checks > on it. > > Do you think this is a good approach? If so, I shall proceed with the > work, and complete the script. If not, what other approach would be > good? > Nice. What parts of the commit message guidelines do you expect to be verifiable, and which parts do you think will be too hard/restrictive to automatically verify? > > Note that the grammar shown below is incomplete and buggy. Do ignore > that for now. > Alright. If you haven't done so already, adding test cases (from existing proper and improper commit messages) would ease understanding. > > (define-peg-string-patterns > "commit <-- module S module S summary NL NL (description NL NL)? > changelog signature? > module <-- (!C !S .)* C > summary <-- (!NL .)* > description <-- (!(NL NL) .)* > changelog <-- entry* > entry <-- bullet S file S section C S change > file <-- word > section <-- LR (!RR .)* RR > change <-- (!(bullet / (NL NL)) .)* > signature <-- signedoffby signatory S email > signedoffby < 'Signed-off-by: ' > signatory <-- (!' <' .)* > email <-- LA (!RA .)* RA > word <- (!S .)* > S < ' ' > C < ':' > NL < '\n' > bullet < '*' > LR < '(' > RR < ')' > LA < '<' > RA < '>'") If this works, I would love for it to be a commit hook. Thanks for looking into this! - Jelle --f403043ef77cb8ce540559b19f7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2017-09-20 17:47 GMT+02:00 Arun Isaac <arunisaac@systemreboot= .net>:
<= br> I have been working on a guile script to automatically check commit
messages -- something like `guix lint' but for commit messages instead<= br> of package definitions. This could help us enforce our commit message
guidelines and avoid screw-ups like the one I did in commit
1ee879e96705e6381c056358b7f426f2cf99c1df. I believe more automation is=
essential and would help us scale better if/when we have more people
with commit access.
Hear, hear.

I have taken the following approach with my script: I have devised a
grammar (shown below) to parse commit messages. Once the parser outputs
a parse tree for the commit message, we can apply any number of checks
on it.

Do you think this is a good approach? If so, I shall proceed with the
work, and complete the script. If not, what other approach would be
good?

Nice. What parts of the commit message guide= lines do you expect to be
verifiable, and which parts do you= think will be too hard/restrictive to
automatically verify?= =C2=A0

Note that the grammar shown below is incomplete and buggy. Do ignore
that for now.
Alright. If you haven't done so alre= ady, adding test cases (from
existing proper and improper co= mmit messages) would ease understanding.=C2=A0

(define-peg-string-patterns
=C2=A0 "commit <-- module S module S summary NL NL (description NL = NL)? changelog signature?
module <-- (!C !S .)* C
summary <-- (!NL .)*
description <-- (!(NL NL) .)*
changelog <-- entry*
entry <-- bullet S file S section C S change
file <-- word
section <-- LR (!RR .)* RR
change <-- (!(bullet / (NL NL)) .)*
signature <-- signedoffby signatory S email
signedoffby < 'Signed-off-by: '
signatory <-- (!' <' .)*
email <-- LA (!RA .)* RA
word <- (!S .)*
S < ' '
C < ':'
NL < '\n'
bullet < '*'
LR < '('
RR < ')'
LA < '<'
RA < '>'")

If this works= , I would love for it to be a commit hook. Thanks for looking into this!

- Jelle

=C2=A0

--f403043ef77cb8ce540559b19f7c--