From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arun Isaac Subject: Re: Automatically checking commit messages Date: Sat, 23 Sep 2017 10:14:55 +0530 Message-ID: References: <9a88d837.ADkAADITH3QAAAAAAAAAAAOtZhgAAAACwQwAAAAAAAW9WABZwo2s@mailjet.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:32938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dvcJY-0007eg-RO for guix-devel@gnu.org; Sat, 23 Sep 2017 00:45:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dvcJV-0001KB-HM for guix-devel@gnu.org; Sat, 23 Sep 2017 00:45:16 -0400 Received: from o127.p8.mailjet.com ([87.253.233.127]:55083) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dvcJV-0001Ix-7i for guix-devel@gnu.org; Sat, 23 Sep 2017 00:45:13 -0400 In-Reply-To: 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: guix-devel > 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? I haven't thought too hard about this. I thought that, if we have a good parser for commit messages, we can later add any number of tests. Anyways, here are a few tests that immediately come to mind: * Check for commit signature. Our existing pre-push hook already does this. * Verify that the modules listed on the first line of the commit message ("gnu: you-get", "guix: build:", etc.) are accurate. * Verify mundane things like capitalization of first word of sentence, period at the end of a sentence, no indentation when a changelog entry continues for more than one line, etc. * Maybe, enforce templates for common commits like updating a package, enabling/disabling tests/parallel-build/parallel-tests, etc. * Verify that the changelog lists all changes in the commit. This might require actually parsing the patch, and may not be easy. > If you haven't done so already, adding test cases (from existing > proper and improper commit messages) would ease understanding. I will work on this script further, and post a patch once I have something more complete. >> This is a good idea, and it would be even better if that same thing >> could be used to generate a commit message with all the automatable >> pieces pre-filled, with only the human parts left to the user. This is an interesting thought. I also just found out that git supports commit message templates, and I wonder if it could be useful. https://robots.thoughtbot.com/better-commit-messages-with-a-gitmessage-temp= late > FWIW 'magit' can already fill out file names and variables by navigating > to the hunks in the diff buffer and pressing 'C'. True, magit is very useful in that regard. But, at least for common commits like updating patches, it would help to have something more automated than that. =