git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Bernt Hansen <bernt@alumni.uwaterloo.ca>,
	git@vger.kernel.org
Subject: Re: [PATCH] Force new line at end of commit message
Date: Wed, 26 Dec 2007 11:36:25 -0800	[thread overview]
Message-ID: <7v4pe5nt8m.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20071225044202.GO14735@spearce.org> (Shawn O. Pearce's message of "Mon, 24 Dec 2007 23:42:02 -0500")

"Shawn O. Pearce" <spearce@spearce.org> writes:

> There is nothing that requires that a commit object end with an LF.
> So tools that make this assumption (that there is a trailing LF)
> while processing the body of a commit message are quite simply
> broken.
> ...
> IMHO git-gui is producing valid commit messages, and always does
> so with no trailing LF, and any tool that is assuming a trailing
> LF is always present is broken.

I would not go that far, even though I would agree that the
consumers of existing commits should be lenient and the creators
of new commits should be strict.

Now, "strict" and "lenient" are both relative to some yardstick,
but relative to what?  I would say that the UI layer of "git the
SCM" is about helping humans create commit messages for human
consumption, even though the low-level commit objects are
equipped to record any binary blob (including NUL byte).

As UI layer programs, I think "git commit" and "git rebase -i"
can and should be stricter than allowing "arbitrary binary
blobs".  Namely, they should make sure what they produce are
good text messages (and a good text message ends with a LF ---
prepare a file with an incomplete line, run "cat file" from
interactive shell on it, and see your prompt tucked at the end
before arguing otherwise).

So how about doing something like this?

---
 git-rebase--interactive.sh |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 090c3e5..d0d83c3 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -215,15 +215,17 @@ make_squash_message () {
 		COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
 			< "$SQUASH_MSG" | tail -n 1)+1))
 		echo "# This is a combination of $COUNT commits."
-		sed -n "2,\$p" < "$SQUASH_MSG"
+		sed -e 1d -e '2,/^./{
+			/^$/d
+		}' <"$SQUASH_MSG"
 	else
 		COUNT=2
 		echo "# This is a combination of two commits."
 		echo "# The first commit's message is:"
 		echo
 		git cat-file commit HEAD | sed -e '1,/^$/d'
-		echo
 	fi
+	echo
 	echo "# This is the $(nth_string $COUNT) commit message:"
 	echo
 	git cat-file commit $1 | sed -e '1,/^$/d'

  parent reply	other threads:[~2007-12-26 19:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-20  0:35 git rebase -i / git-gui bug Bernt Hansen
2007-12-20  4:47 ` Bernt Hansen
2007-12-20  7:12   ` [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary Shawn O. Pearce
2007-12-20  7:15     ` Junio C Hamano
2007-12-20  7:31       ` Shawn O. Pearce
2007-12-20  9:35         ` Junio C Hamano
2007-12-26 23:48           ` Junio C Hamano
2007-12-29 13:26             ` Johannes Schindelin
2007-12-20  7:52     ` Matthieu Moy
2007-12-24 14:31 ` [PATCH] Force new line at end of commit message Bernt Hansen
2007-12-24 17:38   ` Johannes Schindelin
2007-12-25  4:42     ` Shawn O. Pearce
2007-12-25  9:34       ` Junio C Hamano
2007-12-26 17:47       ` Bernt Hansen
2007-12-27  4:19         ` Shawn O. Pearce
2007-12-28  2:15           ` [PATCH] git-gui: Make commit log messages end with a newline Bernt Hansen
2007-12-26 19:36       ` Junio C Hamano [this message]
2007-12-29 13:31         ` [PATCH] Force new line at end of commit message Johannes Schindelin
2007-12-30  0:19           ` Junio C Hamano
2007-12-30 10:26             ` Johannes Schindelin
2007-12-30 10:51               ` Junio C Hamano
2007-12-30 11:03                 ` Johannes Schindelin
2007-12-30 11:45                   ` Junio C Hamano
2007-12-30 11:57                     ` しらいしななこ
2007-12-30 12:21                       ` Junio C Hamano
2007-12-30 12:05                     ` Junio C Hamano
2007-12-30 15:50                     ` Johannes Schindelin
2007-12-25  4:46   ` Shawn O. Pearce
     [not found] <200712301158.lBUBwT3u004608@mi1.bluebottle.com>
2007-12-30 15:51 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v4pe5nt8m.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bernt@alumni.uwaterloo.ca \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).