Nonempty second line in commit message (??)

Nonempty second line in commit message (??)

[Jan D.]

Hi.

While commiting I got this error:

"Nonempty second line in commit message".

Why can't the second line be non-empty?  Are commit message limitied to one line now?  Or must the second be empty and then the rest be non-empty?  Or is the error message just extraordinary bad?

	Jan D.

Re: Nonempty second line in commit message (??)

[Ivan Shmakov]

>>>>> Jan D <jan.h.d@swipnet.se> writes:

 > While commiting I got this error:

 > "Nonempty second line in commit message".

 > Why can't the second line be non-empty?  Are commit message limitied
 > to one line now?  Or must the second be empty and then the rest be
 > non-empty?

	Yes.

	The first line is reserved for the summary, which should be a
	/concise/ overall description of the change.  For one thing, it
	should deliver the essence of the change even if you’re reading
	through emacs-diffs@ /and/ the messages there are listed
	one-per-line (assuming the 80 CPL IBM standard.)

	Naturally, such summary should never be long enough to warrant a
	second (or third, or…) line.

	The summary forms a paragraph on its own, so the usual
	ChangeLog-style details should follow after a customary
	“paragraph break” empty line.

 > Or is the error message just extraordinary bad?

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: Nonempty second line in commit message (??)

[Paul Eggert]

Jan D. wrote:
> Why can't the second line be non-empty?

It's the usual style for Git commit messages.  This is documented in CONTRIBUTE. 
  Perhaps the error message should cite CONTRIBUTE?

Re: Nonempty second line in commit message (??)

[Jan D.]

> 29 mar 2015 kl. 00:33 skrev Paul Eggert <eggert@cs.ucla.edu>:
> 
> Jan D. wrote:
>> Why can't the second line be non-empty?
> 
> It's the usual style for Git commit messages.  This is documented in CONTRIBUTE.  Perhaps the error message should cite CONTRIBUTE?

That would be more helpful.

	Jan D.

Re: Nonempty second line in commit message (??)

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 110 bytes --]

Jan D. wrote:
> That would be more helpful.

OK, thanks, I did that in master, as part of the attached patch.

[-- Attachment #2: 0001-Fix-commit-msg-to-cite-CONTRIBUTE.patch --]
[-- Type: text/x-patch, Size: 4794 bytes --]

From 19f8e0231d1754658e712e21af32f2f4e04bdfdf Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 29 Mar 2015 13:03:55 -0700
Subject: [PATCH] Fix 'commit-msg' to cite 'CONTRIBUTE'

As suggested in:
http://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00947.html
Also, have the two files match better.
* CONTRIBUTE: Match what's in build-aux/git-hooks/commit-msg.
* build-aux/git-hooks/commit-msg: Mention 'CONTRIBUTE'.
---
 CONTRIBUTE                     | 16 +++++++++++-----
 ChangeLog                      |  9 +++++++++
 build-aux/git-hooks/commit-msg | 16 ++++++++--------
 3 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/CONTRIBUTE b/CONTRIBUTE
index 7c40227..c723143 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE
@@ -37,16 +37,17 @@ specify the actual author; the committer defaults to you.
 When using git, commit messages should use ChangeLog format, with the
 following modifications:
 
-- Add a single short line explaining the change, then an empty line,
-  then unindented ChangeLog entries.
+- Start with a single unindented summary line explaining the change,
+  then an empty line, then unindented ChangeLog entries.
 
   You can use various Emacs functions to ease this process; see (info
   "(emacs)Change Log Commands") or
   http://www.gnu.org/software/emacs/manual/html_node/emacs/Change-Log-Commands.html.
 
-- The summary line is limited to 72 characters (enforced by a commit
-  hook). If you have trouble making that a good summary, add a
-  paragraph below it, before the individual file descriptions.
+- Limit lines in commit messages to 78 characters, unless they consist
+  of a single word of at most 140 characters.  If you have trouble
+  fitting the summary into 78 characters, add a summarizing paragraph
+  below the empty line and before the individual file descriptions.
 
 - If only a single file is changed, the summary line can be the normal
   file first line (starting with the asterisk).  Then there is no
@@ -57,6 +58,11 @@ following modifications:
   the rationale for a change; that can be done in the commit message
   between the summary line and the file entries.
 
+- Commit messages should contain only printable UTF-8 characters.
+
+- Commit messages should not contained the "Signed-off-by:" lines that
+  are used in some other projects.
+
 ** ChangeLog notes
 
 - Emacs generally follows the GNU coding standards when it comes to
diff --git a/ChangeLog b/ChangeLog
index a489ab9..f550c6d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2015-03-29  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Fix 'commit-msg' to cite 'CONTRIBUTE'
+	As suggested in:
+	http://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00947.html
+	Also, have the two files match better.
+	* CONTRIBUTE: Match what's in build-aux/git-hooks/commit-msg.
+	* build-aux/git-hooks/commit-msg: Mention 'CONTRIBUTE'.
+
 2015-03-23  Andreas Schwab  <schwab@suse.de>
 
 	* configure.ac: Fix jpeg version check to work with gcc >= 5.
diff --git a/build-aux/git-hooks/commit-msg b/build-aux/git-hooks/commit-msg
index 31df5ce..13a0535 100755
--- a/build-aux/git-hooks/commit-msg
+++ b/build-aux/git-hooks/commit-msg
@@ -63,7 +63,7 @@ exec $awk '
   /^#/ { next }
 
   !/^.*$/ {
-    print "Invalid character (not UTF-8) in commit message"
+    print "Invalid character (not UTF-8) in commit message; see 'CONTRIBUTE'"
     status = 1
   }
 
@@ -77,13 +77,13 @@ exec $awk '
       sub(/^squash! /, "")
 
     if ($0 ~ "^" space) {
-      print "White space at start of commit message'\''s first line"
+      print "White space at start of commit message'\''s first line; see 'CONTRIBUTE'"
       status = 1
     }
   }
 
   nlines == 2 && $0 ~ non_space {
-    print "Nonempty second line in commit message"
+    print "Nonempty second line in commit message; see 'CONTRIBUTE'"
     status = 1
   }
 
@@ -97,28 +97,28 @@ exec $awk '
   }
 
   78 < length && $0 ~ space {
-    print "Line longer than 78 characters in commit message"
+    print "Line longer than 78 characters in commit message; see 'CONTRIBUTE'"
     status = 1
   }
 
   140 < length {
-    print "Word longer than 140 characters in commit message"
+    print "Word longer than 140 characters in commit message; see 'CONTRIBUTE'"
     status = 1
   }
 
   /^Signed-off-by: / {
-    print "'\''Signed-off-by:'\'' in commit message"
+    print "'\''Signed-off-by:'\'' in commit message; see 'CONTRIBUTE'"
     status = 1
   }
 
   $0 ~ non_print {
-    print "Unprintable character in commit message"
+    print "Unprintable character in commit message; see 'CONTRIBUTE'"
     status = 1
   }
 
   END {
     if (nlines == 0) {
-      print "Empty commit message"
+      print "Empty commit message; see 'CONTRIBUTE'"
       status = 1
     }
     exit status
-- 
2.1.0

Re: Nonempty second line in commit message (??)

[Stefan Monnier]

> While commiting I got this error:

> "Nonempty second line in commit message".

> Why can't the second line be non-empty?

Git considers "the summary" (displayed in short logs and things like
that) to be the concatenation of all lines until the first empty line.
I think this convention sucks (if you forget such an empty line,
it leads to ridiculously long "summaries", and it forces the addition
of an empty line at a spot where you don't always want one).


        Stefan

Re: Nonempty second line in commit message (??)

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

 >> While commiting I got this error: "Nonempty second line in commit
 >> message".

 >> Why can't the second line be non-empty?

 > Git considers "the summary" (displayed in short logs and things like
 > that) to be the concatenation of all lines until the first empty
 > line.  I think this convention sucks (if you forget such an empty
 > line, it leads to ridiculously long "summaries",

	That’s just “the summary is the first paragraph of the entry”
	rule.  One could certainly screw up with this convention in
	place, but that’s also possible with any other convention.

 > and it forces the addition of an empty line at a spot where you don't
 > always want one).

	Any examples for this point?

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: Nonempty second line in commit message (??)

[Stefan Monnier]

>> and it forces the addition of an empty line at a spot where you don't
>> always want one).
> 	Any examples for this point?

If you have a first line that you want cut in the summary as in:

     * mydir/myfile (myfunction): Add an extra semicolon
     except when it's not at the end of line


-- Stefan