[PATCH 3/4] Retain extra blank lines between the summary and the body

This is so that it's possible to have a message that will generate an
email with the first line blank. If the email you're generating is
actually a template, you may have a single line filling in for a
~3-line paragraph, meaning that the space starts with a blank line,
which was impossible before as output from the message-splitting code.

Signed-off-by: Daniel Barkalow <redacted>
---
 pretty.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/pretty.c b/pretty.c
index f82380b..98efac2 100644
--- a/pretty.c
+++ b/pretty.c

@@ -713,7 +713,6 @@ void pp_remainder(enum cmit_fmt fmt,
 		  struct strbuf *sb,
 		  int indent)
 {
-	int first = 1;
 	for (;;) {
 		const char *line = *msg_p;
 		int linelen = get_one_line(line);

@@ -723,12 +722,9 @@ void pp_remainder(enum cmit_fmt fmt,
 			break;
 
 		if (is_empty_line(line, &linelen)) {
-			if (first)
-				continue;
 			if (fmt == CMIT_FMT_SHORT)
 				break;
 		}
-		first = 0;
 
 		strbuf_grow(sb, linelen + indent + 20);
 		if (indent) {

-- 
1.5.4.27.gf6864

Daniel Barkalow [off-list ref] writes:

I have to wonder if this regresses the normal codepath to
cleanse commit messages that have extra blanks at the
beginning.

On Wed, 6 Feb 2008, Junio C Hamano wrote:

Daniel Barkalow [off-list ref] writes:

quoted

This is so that it's possible to have a message that will generate an
email with the first line blank. If the email you're generating is
actually a template, you may have a single line filling in for a
~3-line paragraph, meaning that the space starts with a blank line,
which was impossible before as output from the message-splitting code.

Signed-off-by: Daniel Barkalow <redacted>
---
 pretty.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/pretty.c b/pretty.c
index f82380b..98efac2 100644
--- a/pretty.c
+++ b/pretty.c

@@ -713,7 +713,6 @@ void pp_remainder(enum cmit_fmt fmt,
 		  struct strbuf *sb,
 		  int indent)
 {
-	int first = 1;
 	for (;;) {
 		const char *line = *msg_p;
 		int linelen = get_one_line(line);

@@ -723,12 +722,9 @@ void pp_remainder(enum cmit_fmt fmt,
 			break;
 
 		if (is_empty_line(line, &linelen)) {
-			if (first)
-				continue;
 			if (fmt == CMIT_FMT_SHORT)
 				break;
 		}
-		first = 0;
 
 		strbuf_grow(sb, linelen + indent + 20);
 		if (indent) {

I have to wonder if this regresses the normal codepath to
cleanse commit messages that have extra blanks at the
beginning.

When we discussed this ages ago, I think we came to the conclusion that it 
didn't matter. The code doesn't remove extra blank lines from between body 
paragraphs, so it's a bit arbitrary to remove them between the first line 
and the following paragraph. And people tend not to have commit messages 
with blank lines there (in fact, I think git strips them out on commit).

	-Daniel
*This .sig left intentionally blank*

Daniel Barkalow [off-list ref] writes:

When we discussed this ages ago, I think we came to the conclusion that it 
didn't matter. The code doesn't remove extra blank lines from between body 
paragraphs, so it's a bit arbitrary to remove them between the first line 
and the following paragraph. And people tend not to have commit messages 
with blank lines there (in fact, I think git strips them out on commit).

Ah, then "Stripping only at the beginning is inconsistent and
wrong" would be a better description.  Then that's fine by me in
either case.

Thanks for a reminder.