unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Nonempty second line in commit message (??)
@ 2015-03-28 22:09 Jan D.
  2015-03-28 22:27 ` Ivan Shmakov
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Jan D. @ 2015-03-28 22:09 UTC (permalink / raw)
  To: Emacs-Devel devel

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.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Nonempty second line in commit message (??)
  2015-03-28 22:09 Nonempty second line in commit message (??) Jan D.
@ 2015-03-28 22:27 ` Ivan Shmakov
  2015-03-28 23:33 ` Paul Eggert
  2015-03-29  4:05 ` Stefan Monnier
  2 siblings, 0 replies; 8+ messages in thread
From: Ivan Shmakov @ 2015-03-28 22:27 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Nonempty second line in commit message (??)
  2015-03-28 22:09 Nonempty second line in commit message (??) Jan D.
  2015-03-28 22:27 ` Ivan Shmakov
@ 2015-03-28 23:33 ` Paul Eggert
  2015-03-29  7:45   ` Jan D.
  2015-03-29  4:05 ` Stefan Monnier
  2 siblings, 1 reply; 8+ messages in thread
From: Paul Eggert @ 2015-03-28 23:33 UTC (permalink / raw)
  To: Jan D., Emacs-Devel devel

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?



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Nonempty second line in commit message (??)
  2015-03-28 22:09 Nonempty second line in commit message (??) Jan D.
  2015-03-28 22:27 ` Ivan Shmakov
  2015-03-28 23:33 ` Paul Eggert
@ 2015-03-29  4:05 ` Stefan Monnier
  2015-03-29 11:10   ` Ivan Shmakov
  2 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2015-03-29  4:05 UTC (permalink / raw)
  To: Jan D.; +Cc: Emacs-Devel devel

> 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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Nonempty second line in commit message (??)
  2015-03-28 23:33 ` Paul Eggert
@ 2015-03-29  7:45   ` Jan D.
  2015-03-29 20:10     ` Paul Eggert
  0 siblings, 1 reply; 8+ messages in thread
From: Jan D. @ 2015-03-29  7:45 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Emacs-Devel devel


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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Nonempty second line in commit message (??)
  2015-03-29  4:05 ` Stefan Monnier
@ 2015-03-29 11:10   ` Ivan Shmakov
  2015-03-29 20:54     ` Stefan Monnier
  0 siblings, 1 reply; 8+ messages in thread
From: Ivan Shmakov @ 2015-03-29 11:10 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Nonempty second line in commit message (??)
  2015-03-29  7:45   ` Jan D.
@ 2015-03-29 20:10     ` Paul Eggert
  0 siblings, 0 replies; 8+ messages in thread
From: Paul Eggert @ 2015-03-29 20:10 UTC (permalink / raw)
  To: Jan D.; +Cc: Emacs-Devel devel

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


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: Nonempty second line in commit message (??)
  2015-03-29 11:10   ` Ivan Shmakov
@ 2015-03-29 20:54     ` Stefan Monnier
  0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2015-03-29 20:54 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2015-03-29 20:54 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-28 22:09 Nonempty second line in commit message (??) Jan D.
2015-03-28 22:27 ` Ivan Shmakov
2015-03-28 23:33 ` Paul Eggert
2015-03-29  7:45   ` Jan D.
2015-03-29 20:10     ` Paul Eggert
2015-03-29  4:05 ` Stefan Monnier
2015-03-29 11:10   ` Ivan Shmakov
2015-03-29 20:54     ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).