{"thread":{"id":"13127","subject":"Re: [GIT PULL] sh updates for 2.6.25","startedAt":"2008-04-15T18:01:36Z","lastAt":"2008-04-27T19:04:29Z","messageCount":17,"participants":["Linus Torvalds","Paul Mundt","Junio C Hamano","Jakub Narebski","Miklos Vajna","Alex Riesen","David Woodhouse"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74460","messageId":"alpine.LFD.1.00.0804151048060.2879@woody.linux-foundation.org","threadId":"13127","inReplyTo":"20080415172333.GA29489@linux-sh.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-15T18:01:36Z","receivedAt":"2008-04-15T18:01:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 16 Apr 2008, Paul Mundt wrote:\n>\n> Please pull from:\n> \n> \tgit://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.25.git\n\nPaul, your git tree is odd. Not quite corrupt, but it doesn't really \nfollow the rules either.\n\nIn particular, it has empty lines at the top of those commits, and I \nwonder how you created them. \n\nDoing things like \"git log\" will ignore the spurious empty lines, but they \ncan be seen with things like \"git cat-file\", eg\n\n\tgit cat-file commit fd785d6b18b930b76ad5076eed6e9af43195b281 \n\nand I wonder if you used a buggy version of git, or whether you perhaps \nhave some scripts that import these commits from the outside and uses some \nlow-level commands that can generate these kinds of subtly bogus commits.\n\nThe reason I noticed is that it screws up the git merge summary, which \nwill take the first line of each commit it merges (_without_ the \"skip \nempty lines\" logic) to generate the summary of the merge.\n\nI think we should fix that git merge summary code to allow for this bad \nbehaviour, but I also want to know why such corrupt commits exist in the \nfirst place. What toolchain do you use to create that commit? We should \nfix that too!\n\nJunio? Something like this for the merge summary code? (It also turns an \nempty commit message with just whitespace in the commit message into the \nSHA1 hex string)\n\n\t\tLinus\n\n----\n builtin-fmt-merge-msg.c |   10 +++++++++-\n 1 files changed, 9 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c\nindex ebb3f37..7077d52 100644\n--- a/builtin-fmt-merge-msg.c\n+++ b/builtin-fmt-merge-msg.c\n@@ -201,6 +201,15 @@ static void shortlog(const char *name, unsigned char *sha1,\n \t\t\tcontinue;\n \n \t\tbol = strstr(commit->buffer, \"\\n\\n\");\n+\t\tif (bol) {\n+\t\t\tunsigned char c;\n+\t\t\tdo {\n+\t\t\t\tc = *++bol;\n+\t\t\t} while (isspace(c));\n+\t\t\tif (!c)\n+\t\t\t\tbol = NULL;\n+\t\t}\n+\n \t\tif (!bol) {\n \t\t\tappend_to_list(&subjects, xstrdup(sha1_to_hex(\n \t\t\t\t\t\t\tcommit->object.sha1)),\n@@ -208,7 +217,6 @@ static void shortlog(const char *name, unsigned char *sha1,\n \t\t\tcontinue;\n \t\t}\n \n-\t\tbol += 2;\n \t\teol = strchr(bol, '\\n');\n \t\tif (eol) {\n \t\t\toneline = xmemdupz(bol, eol - bol);\n"},{"id":"74462","messageId":"alpine.LFD.1.00.0804151115250.2879@woody.linux-foundation.org","threadId":"13127","inReplyTo":"alpine.LFD.1.00.0804151048060.2879@woody.linux-foundation.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-15T18:18:39Z","receivedAt":"2008-04-15T18:18:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 15 Apr 2008, Linus Torvalds wrote:\n> \n> Paul, your git tree is odd. Not quite corrupt, but it doesn't really \n> follow the rules either.\n\nAnyway, I pulled the result (with my version of git that removes empty \nspace at the beginning for the merge summary), and pushed it out. So it's \nmerged, but I'd still like to know what tool actually created those extra \nspaces in the commit..\n\nA regular \"git commit\" or \"git am\" should always strip whitespace. I \nassume it's something like stgit or other?\n\n\t\t\t\tLinus\n"},{"id":"74464","messageId":"20080415183023.GA23098@linux-sh.org","threadId":"13127","inReplyTo":"alpine.LFD.1.00.0804151048060.2879@woody.linux-foundation.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Paul Mundt","fromEmail":"lethal@linux-sh.org","sentAt":"2008-04-15T18:30:23Z","receivedAt":"2008-04-15T18:30:23Z","isPatch":false,"sender":{"key":"lethal@linux-sh.org","avatar":null},"body":"On Tue, Apr 15, 2008 at 11:01:36AM -0700, Linus Torvalds wrote:\n> On Wed, 16 Apr 2008, Paul Mundt wrote:\n> >\n> > Please pull from:\n> > \n> > \tgit://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.25.git\n> \n> Paul, your git tree is odd. Not quite corrupt, but it doesn't really \n> follow the rules either.\n> \n> In particular, it has empty lines at the top of those commits, and I \n> wonder how you created them. \n> \n> Doing things like \"git log\" will ignore the spurious empty lines, but they \n> can be seen with things like \"git cat-file\", eg\n> \n> \tgit cat-file commit fd785d6b18b930b76ad5076eed6e9af43195b281 \n> \n> and I wonder if you used a buggy version of git, or whether you perhaps \n> have some scripts that import these commits from the outside and uses some \n> low-level commands that can generate these kinds of subtly bogus commits.\n\nIt was a combination of mbox munging and git-am, I checked with git log\nand thought things were ok, but I wasn't aware that it stripped out empty\nlines. cat-file shows that it was just the 2 patches from Andrew that had\nthis particular problem. I had stripped out the subject and thought the\nfirst line would be used for the merge summary, but it looks like git-am\nsimply wrote out an empty line and inserted one after that before the\nrest of the summary.\n\nI've pushed out updated patches that have this corrected, so please pull\nagain.\n"},{"id":"74466","messageId":"7vr6d7x8nj.fsf@gitster.siamese.dyndns.org","threadId":"13127","inReplyTo":"alpine.LFD.1.00.0804151048060.2879@woody.linux-foundation.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-15T18:41:52Z","receivedAt":"2008-04-15T18:41:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> Junio? Something like this for the merge summary code? (It also turns an \n> empty commit message with just whitespace in the commit message into the \n> SHA1 hex string)\n\nYeah, your patch makes sense, but it also makes me wonder if we should fix\nthe code in pretty.c::parse_commit_header() that grabs the \"subject\" line,\nand use format_commit_message() with \"%s\" format here.  Interested people\nthen can enhance it to take custom format string.\n\n> \t\tLinus\n>\n> ----\n>  builtin-fmt-merge-msg.c |   10 +++++++++-\n>  1 files changed, 9 insertions(+), 1 deletions(-)\n>\n> diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c\n> index ebb3f37..7077d52 100644\n> --- a/builtin-fmt-merge-msg.c\n> +++ b/builtin-fmt-merge-msg.c\n> @@ -201,6 +201,15 @@ static void shortlog(const char *name, unsigned char *sha1,\n>  \t\t\tcontinue;\n>  \n>  \t\tbol = strstr(commit->buffer, \"\\n\\n\");\n> +\t\tif (bol) {\n> +\t\t\tunsigned char c;\n> +\t\t\tdo {\n> +\t\t\t\tc = *++bol;\n> +\t\t\t} while (isspace(c));\n> +\t\t\tif (!c)\n> +\t\t\t\tbol = NULL;\n> +\t\t}\n> +\n>  \t\tif (!bol) {\n>  \t\t\tappend_to_list(&subjects, xstrdup(sha1_to_hex(\n>  \t\t\t\t\t\t\tcommit->object.sha1)),\n> @@ -208,7 +217,6 @@ static void shortlog(const char *name, unsigned char *sha1,\n>  \t\t\tcontinue;\n>  \t\t}\n>  \n> -\t\tbol += 2;\n>  \t\teol = strchr(bol, '\\n');\n>  \t\tif (eol) {\n>  \t\t\toneline = xmemdupz(bol, eol - bol);\n"},{"id":"74475","messageId":"m3ej97rmc0.fsf@localhost.localdomain","threadId":"13127","inReplyTo":"alpine.LFD.1.00.0804151048060.2879@woody.linux-foundation.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-15T18:43:24Z","receivedAt":"2008-04-15T18:43:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> Paul, your git tree is odd. Not quite corrupt, but it doesn't really \n> follow the rules either.\n> \n> In particular, it has empty lines at the top of those commits, and I \n> wonder how you created them. \n\n> The reason I noticed is that it screws up the git merge summary, which \n> will take the first line of each commit it merges (_without_ the \"skip \n> empty lines\" logic) to generate the summary of the merge.\n> \n> I think we should fix that git merge summary code to allow for this bad \n> behaviour, but I also want to know why such corrupt commits exist in the \n> first place. What toolchain do you use to create that commit? We should \n> fix that too!\n\nI seem to remember (but I might be mistaken) that this issue was\ncorrected by some patch on git mailing list already...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"74472","messageId":"alpine.LFD.1.00.0804151222350.2879@woody.linux-foundation.org","threadId":"13127","inReplyTo":"20080415183023.GA23098@linux-sh.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-15T19:56:50Z","receivedAt":"2008-04-15T19:56:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 16 Apr 2008, Paul Mundt wrote:\n> \n> It was a combination of mbox munging and git-am, I checked with git log\n> and thought things were ok, but I wasn't aware that it stripped out empty\n> lines. cat-file shows that it was just the 2 patches from Andrew that had\n> this particular problem. I had stripped out the subject and thought the\n> first line would be used for the merge summary, but it looks like git-am\n> simply wrote out an empty line and inserted one after that before the\n> rest of the summary.\n\nAhh, looks like a git-am buglet then. It will indeed turn an empty subject \nline into an empty first line.\n\nWe should run \"git stripspace\" on the whole thing, so maybe a patch \nsomething like the appended will help.\n\nNOTE! Totally untested! Beware the patch!\n\n> I've pushed out updated patches that have this corrected, so please pull\n> again.\n\nWell, since I pulled your previous one anyway, and since we should fix \ngit for any fallout like this _anyway_, I didn't so much worry about this \none-time event, as about avoiding this happening a lot in the future.\n\nWe've had other workflows generate empty lines in commits, so we already \nsupport stripping them out for other reasons.\n\n\t\t\tLinus\n---\n git-am.sh |   23 +++++++++--------------\n 1 files changed, 9 insertions(+), 14 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex ac5c388..432d9fe 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -107,7 +107,7 @@ It does not apply to blobs recorded in its index.\"\n     # patch did not touch, so recursive ends up canceling them,\n     # saying that we reverted all those changes.\n \n-    eval GITHEAD_$his_tree='\"$SUBJECT\"'\n+    eval GITHEAD_$his_tree='\"$FIRSTLINE\"'\n     export GITHEAD_$his_tree\n     git-merge-recursive $orig_tree -- HEAD $his_tree || {\n \t    git rerere\n@@ -117,10 +117,6 @@ It does not apply to blobs recorded in its index.\"\n     unset GITHEAD_$his_tree\n }\n \n-reread_subject () {\n-\tgit stripspace <\"$1\" | sed -e 1q\n-}\n-\n prec=4\n dotest=\".dotest\"\n sign= utf8=t keep= skip= interactive= resolved= binary= rebasing=\n@@ -331,7 +327,11 @@ do\n \t\t\techo \"Patch is empty.  Was it split wrong?\"\n \t\t\tstop_here $this\n \t\t}\n-\t\tgit stripspace < \"$dotest/msg\" > \"$dotest/msg-clean\"\n+\t\tSUBJECT=\"$(sed -n '/^Subject/ s/Subject: //p' \"$dotest/info\")\"\n+\t\tcase \"$keep_subject\" in -k)  SUBJECT=\"[PATCH] $SUBJECT\" ;; esac\n+\n+\t\t(echo \"$SUBJECT\" ; echo ; cat \"$dotest/msg\") |\n+\t\t\tgit stripspace > \"$dotest/msg-clean\"\n \t\t;;\n \tesac\n \n@@ -347,9 +347,6 @@ do\n \n \texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE\n \n-\tSUBJECT=\"$(sed -n '/^Subject/ s/Subject: //p' \"$dotest/info\")\"\n-\tcase \"$keep_subject\" in -k)  SUBJECT=\"[PATCH] $SUBJECT\" ;; esac\n-\n \tcase \"$resume\" in\n \t'')\n \t    if test '' != \"$SIGNOFF\"\n@@ -368,10 +365,8 @@ do\n \t\tADD_SIGNOFF=\n \t    fi\n \t    {\n-\t\tprintf '%s\\n' \"$SUBJECT\"\n \t\tif test -s \"$dotest/msg-clean\"\n \t\tthen\n-\t\t\techo\n \t\t\tcat \"$dotest/msg-clean\"\n \t\tfi\n \t\tif test '' != \"$ADD_SIGNOFF\"\n@@ -388,6 +383,7 @@ do\n \t\t\t;;\n \t\tesac\n \tesac\n+\tFIRSTLINE=$(head -1 \"$dotest/final-commit\")\n \n \tresume=\n \tif test \"$interactive\" = t\n@@ -408,7 +404,6 @@ do\n \t\t[aA]*) action=yes interactive= ;;\n \t\t[nN]*) action=skip ;;\n \t\t[eE]*) git_editor \"$dotest/final-commit\"\n-\t\t       SUBJECT=$(reread_subject \"$dotest/final-commit\")\n \t\t       action=again ;;\n \t\t[vV]*) action=again\n \t\t       LESS=-S ${PAGER:-less} \"$dotest/patch\" ;;\n@@ -431,7 +426,7 @@ do\n \t\tstop_here $this\n \tfi\n \n-\tprintf 'Applying %s\\n' \"$SUBJECT\"\n+\tprintf 'Applying %s\\n' \"$FIRSTLINE\"\n \n \tcase \"$resolved\" in\n \t'')\n@@ -489,7 +484,7 @@ do\n \ttree=$(git write-tree) &&\n \tparent=$(git rev-parse --verify HEAD) &&\n \tcommit=$(git commit-tree $tree -p $parent <\"$dotest/final-commit\") &&\n-\tgit update-ref -m \"$GIT_REFLOG_ACTION: $SUBJECT\" HEAD $commit $parent ||\n+\tgit update-ref -m \"$GIT_REFLOG_ACTION: $FIRSTLINE\" HEAD $commit $parent ||\n \tstop_here $this\n \n \tif test -x \"$GIT_DIR\"/hooks/post-applypatch\n"},{"id":"74498","messageId":"20080416003725.GF8387@genesis.frugalware.org","threadId":"13127","inReplyTo":"m3ej97rmc0.fsf@localhost.localdomain","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-04-16T00:37:25Z","receivedAt":"2008-04-16T00:37:25Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Apr 15, 2008 at 11:43:24AM -0700, Jakub Narebski <jnareb@gmail.com> wrote:\n> I seem to remember (but I might be mistaken) that this issue was\n> corrected by some patch on git mailing list already...\n\nIf we are at it, I had a similar bugreport: If one doesn't use an empty\nline after the first line in the commit message, a git-format-patch +\ngit-am combo will strip newlines from the commit message:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/73755\n\nThere, you suggested to modify git-format-patch, but I haven't come up\nwith such a patch nor anybody else.\n\nActually I recently tried to make one but I got lost in pretty.c and\nlog-tree.c. :-)\n\nWhat I would like to do is just to change the current:\n\n----\nline1\n line2\n line3\n----\n\noutput to:\n\n----\nline1\n\nline2\nline3\n----\n"},{"id":"74510","messageId":"20080416010605.GG8387@genesis.frugalware.org","threadId":"13127","inReplyTo":"20080416003725.GF8387@genesis.frugalware.org","subject":"[PATCH] format-patch: Make sure the subject is always a one-liner","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-04-16T01:06:05Z","receivedAt":"2008-04-16T01:06:05Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"If the commit message has no empty line after the first line, we need to\ninsert a newline after the first, so that the newlines won't be removed\nfrom the commit message for example when they are applied using git-am.\n\nSigned-off-by: Miklos Vajna <vmiklos@frugalware.org>\n---\n\nOn Wed, Apr 16, 2008 at 02:37:25AM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:\n> If we are at it, I had a similar bugreport: If one doesn't use an\n> empty\n> line after the first line in the commit message, a git-format-patch +\n> git-am combo will strip newlines from the commit message:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/73755\n>\n> There, you suggested to modify git-format-patch, but I haven't come up\n> with such a patch nor anybody else.\n>\n> Actually I recently tried to make one but I got lost in pretty.c and\n> log-tree.c. :-)\n\nOk, here is a try. It does the trick for me, but this it the first time\nI touch pretty.c so feel free to point out if I did something wrong ;-)\n\nThanks.\n\n pretty.c |    6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/pretty.c b/pretty.c\nindex 6c04176..45a5679 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -653,6 +653,7 @@ void pp_title_line(enum cmit_fmt fmt,\n \n \tstrbuf_init(&title, 80);\n \n+\tint check_empty = 1;\n \tfor (;;) {\n \t\tconst char *line = *msg_p;\n \t\tint linelen = get_one_line(line);\n@@ -666,7 +667,10 @@ void pp_title_line(enum cmit_fmt fmt,\n \t\t\tif (fmt == CMIT_FMT_EMAIL) {\n \t\t\t\tstrbuf_addch(&title, '\\n');\n \t\t\t}\n-\t\t\tstrbuf_addch(&title, ' ');\n+\t\t\tif (check_empty && strcmp(line, \"\\n\")) {\n+\t\t\t\tcheck_empty = 0;\n+\t\t\t\tstrbuf_addch(&title, '\\n');\n+\t\t\t}\n \t\t}\n \t\tstrbuf_add(&title, line, linelen);\n \t}\n-- \n1.5.5\n"},{"id":"74502","messageId":"7vd4oqwkev.fsf@gitster.siamese.dyndns.org","threadId":"13127","inReplyTo":"20080416003725.GF8387@genesis.frugalware.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-16T03:25:28Z","receivedAt":"2008-04-16T03:25:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miklos Vajna <vmiklos@frugalware.org> writes:\n\n> On Tue, Apr 15, 2008 at 11:43:24AM -0700, Jakub Narebski <jnareb@gmail.com> wrote:\n>> I seem to remember (but I might be mistaken) that this issue was\n>> corrected by some patch on git mailing list already...\n>\n> If we are at it, I had a similar bugreport: If one doesn't use an empty\n> line after the first line in the commit message, a git-format-patch +\n> git-am combo will strip newlines from the commit message:\n\nThat's not a bug but an intended behaviour.  You are triggering \"RFC 2822\nline folding\" of Subject: header.\n"},{"id":"74533","messageId":"20080416084435.GJ8387@genesis.frugalware.org","threadId":"13127","inReplyTo":"7vd4oqwkev.fsf@gitster.siamese.dyndns.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-04-16T08:44:35Z","receivedAt":"2008-04-16T08:44:35Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Apr 15, 2008 at 08:25:28PM -0700, Junio C Hamano <gitster@pobox.com> wrote:\n> > If we are at it, I had a similar bugreport: If one doesn't use an empty\n> > line after the first line in the commit message, a git-format-patch +\n> > git-am combo will strip newlines from the commit message:\n> \n> That's not a bug but an intended behaviour.  You are triggering \"RFC 2822\n> line folding\" of Subject: header.\n\nHm, then is it git-am that would have to be fixed up to properly unfold\nsuch a subject? (I mean not stripping newlines.)\n"},{"id":"74571","messageId":"20080416185449.GA27015@steel.home","threadId":"13127","inReplyTo":"alpine.LFD.1.00.0804151222350.2879@woody.linux-foundation.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-16T18:54:49Z","receivedAt":"2008-04-16T18:54:49Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Tue, Apr 15, 2008 21:56:50 +0200:\n> \n> \n> On Wed, 16 Apr 2008, Paul Mundt wrote:\n> > \n> > It was a combination of mbox munging and git-am, I checked with git log\n> > and thought things were ok, but I wasn't aware that it stripped out empty\n> > lines. cat-file shows that it was just the 2 patches from Andrew that had\n> > this particular problem. I had stripped out the subject and thought the\n> > first line would be used for the merge summary, but it looks like git-am\n> > simply wrote out an empty line and inserted one after that before the\n> > rest of the summary.\n> \n> Ahh, looks like a git-am buglet then. It will indeed turn an empty subject \n> line into an empty first line.\n> \n> We should run \"git stripspace\" on the whole thing, so maybe a patch \n> something like the appended will help.\n> \n> NOTE! Totally untested! Beware the patch!\n> \n\nt4014-format-patch.sh broke. It probably has to be updated\n"},{"id":"74582","messageId":"7v3aplr2pt.fsf_-_@gitster.siamese.dyndns.org","threadId":"13127","inReplyTo":"20080416084435.GJ8387@genesis.frugalware.org","subject":"Re* [GIT PULL] sh updates for 2.6.25","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-16T19:58:54Z","receivedAt":"2008-04-16T19:58:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miklos Vajna <vmiklos@frugalware.org> writes:\n\n> On Tue, Apr 15, 2008 at 08:25:28PM -0700, Junio C Hamano <gitster@pobox.com> wrote:\n>> > If we are at it, I had a similar bugreport: If one doesn't use an empty\n>> > line after the first line in the commit message, a git-format-patch +\n>> > git-am combo will strip newlines from the commit message:\n>> \n>> That's not a bug but an intended behaviour.  You are triggering \"RFC 2822\n>> line folding\" of Subject: header.\n>\n> Hm, then is it git-am that would have to be fixed up to properly unfold\n> such a subject? (I mean not stripping newlines.)\n\n\"Properly unfolding\" by definition means remove LF before WSP at the\nbeginning of the continued lines, so it does not solve it.  \"git am\" is\nprimarily an email acceptance tool, and the mail pathway between the\nsender and the recipient can splice the \"Subject: \" at any point, so the\nreceiver cannot assume that the lines were folded at the place the\noriginator intended them to be folded (often, the sender wanted a single\nline).\n\nBut let's step back a bit.\n\nFirst of all, if you are using git as \"fast filesystem that lets you build\nyour own SCM on top of\", aka \"plumbing\", you can have your commit log\nmessage in any way you want.  \"git-commit-tree\" allows you to record\narbitrary commit log message without whitespace cleansing (it might eat\nNUL, but that would be a bug if it did so), and \"git-cat-file commit\"\nwould give you what you recorded literally.\n\nHowever, if you are using git as a full featured SCM, aka \"Porcelain\", you\nhave to work within the rules of how the world works, which were not set\narbitrarily but came from real world constraints.  \"git-format-patch\" and\n\"git-am\" are two examples of such Porcelain programs.\n\nUnlike olden days when people used CVS and recorded a two-week's worth of\nwork as a single huge commit, we encourage working with many small\ncommits, and we have tools to give you overview of the history without\ndrowning you in the sea of information.  \"git reflog\", \"git branch -v\",\n\"git-log --pretty=oneline\", \"git show-branch\", \"git fmt-merge-msg\",\n\"gitk\", and \"git shortlog\" all are built around the notion that the first\nline of the commit is _special_ in that by reading only that line, there\nshould be enough information for the reader to tell what the commit is\nabout.  Also, emailed patch has the \"Subject: \" line to serve the same\npurpose and by definition that is a single liner.\n\nWhen one adopts the notion of \"a single line at the top summarizes what\nthe commit is about\", it is very natural to call that a \"title\", and\nhaving a blank line between the title and the body to separate them also\nbecomes natural, and it matches how a patch is presented in email, as a\nbonus, so it matches people's expectation.\n\nSo this format is merely a convention when viewed at the \"plumbing\" level,\nbut it is more important than just a convention if you are living at the\n\"Porcelain\" level; if you deviate from that, \"Porcelain\" would not work\nvery well for you.\n\nWe can do two things about \"would not work very well\" part above when you\ndo have a commit whose first paragraph has more then one lines, and\ndealing with such a commit gracefully is important.\n\nPeople who are used to other systems without a good history summarization\ntools can and do write such log messages.  People who make commits on such\nsystems whose commits are imported to git (perhaps even without them\nknowing about it) do not have an incentive to use a short-and-clear single\nline summary in each of their commits, as their system may not give a good\nway to make use of the result of such a practice.\n\nVery old git literally took \"the first line is the summary\" approach,\nwhich meant that the first line of such a multi-line paragraph at the\nbeginning became \"Subject: \", and the message body started in the mid\nsentence.  \"git log --pretty=oneline\" appeared to chomp a sentence in the\nmiddle (while in fact the guilty party who chomped the sentence in the\nmiddle was the committer). People who migrated from CVS hated the loss of\ninformation. Worse yet, because \"rebase\" is implemented in terms of\n\"format-patch piped to am\" (which we can eventually change to use\ngit-sequencer), if you rebase such a commit, you will get an extra empty\nline between the first line and the subsequent lines.\n\nThese days, format-patch was taught to use \"the first paragraph\" as the\nsummarizing first line to avoid chomping a sentence in the middle.  This\nchange did not hurt people who use git \"Porcelain\", as the commit log\nmessage for them is always \"a single line summary, a blank line, and the\nbody\".  The first paragraph is the same as the first line for them.  But\nfor commits that have a multi-line paragraph at the beginning, information\nlossage is avoided this way.  Now the first chunk of the message, even if\nit is splattered over two physical lines, is used as the summary.\n\nThe tools that allocate only one display line for each commit (again,\nformat-patch is one of them because there is only one \"Subject: \" line)\nstill need to cope with this, as they have only one line to work with.\nThe way format-patch and friends do so is to take it as a logically single\nline folded into multiple lines.  format-patch (and --pretty=email)\nhappens to know that the output medium (i.e. rfc 2822 messages) allows to\nexpress the logically single line as multiple physical lines, so its\noutput \"preserves\" the original line breaks, but \"git am\" is in no\nposition to honor it, at least without an extra option to tell it that it\nis safe and meaningful to do so.\n\nSo in short, when you use \"am\", it by design unfolds the \"Subject: \" line\nand there is no bug there.  \"rebase\" being implemented in terms of\n\"format-patch piped to am\" does mangle the message because of this, but\nif anything that is a bug in rebase, and not \"am\".\n\nAnd this is a potential fix to the issue, which was made possible only\nbecause recently \"rebase\" started passing an extra option to \"am\".\n\n-- >8 --\nFrom: Junio C Hamano <gitster@pobox.com>\nDate: Wed, 16 Apr 2008 12:50:48 -0700\nSubject: [PATCH] rebase: do not munge commit log message\n\nTraditionally git-rebase was implemented in terms of \"format-patch\" piped\nto \"am -3\", to strike balance between speed (because it avoids a rather\nexpensive read-tree/merge-recursive machinery most of the time) and\nflexibility (the magic \"-3\" allows it to fall back to 3-way merge as\nnecessary).  However, this combination has one flaw when dealing with a\nnonstandard commit log message format that has more than one lines in the\nfirst paragraph, because such a \"first line\" is formatted as logically a\nsingle line, and unfolded at the applying end.\n\nThis teaches \"git am --rebasing\" to take advantage of the fact that the\nmbox message \"git rebase\" prepares for it records the original commit\nobject name, and that such a commit _is_ available locally.  It reads the\nlog message from the original commit object instead.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n git-am.sh                    |   19 ++++++++++++++-----\n t/t3408-rebase-multi-line.sh |   41 +++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 55 insertions(+), 5 deletions(-)\n create mode 100755 t/t3408-rebase-multi-line.sh\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 245e1db..5a7695e 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -327,11 +327,20 @@ do\n \t\t\techo \"Patch is empty.  Was it split wrong?\"\n \t\t\tstop_here $this\n \t\t}\n-\t\tSUBJECT=\"$(sed -n '/^Subject/ s/Subject: //p' \"$dotest/info\")\"\n-\t\tcase \"$keep_subject\" in -k)  SUBJECT=\"[PATCH] $SUBJECT\" ;; esac\n-\n-\t\t(echo \"$SUBJECT\" ; echo ; cat \"$dotest/msg\") |\n-\t\t\tgit stripspace > \"$dotest/msg-clean\"\n+\t\tif test -f \"$dotest/rebasing\" &&\n+\t\t\tcommit=$(sed -e 's/^From \\([0-9a-f]*\\) .*/\\1/' \\\n+\t\t\t\t-e q \"$dotest/$msgnum\") &&\n+\t\t\ttest \"$(git cat-file -t \"$commit\")\" = commit\n+\t\tthen\n+\t\t\tgit cat-file commit \"$commit\" |\n+\t\t\tsed -e '1,/^$/d' >\"$dotest/msg-clean\"\n+\t\telse\n+\t\t\tSUBJECT=\"$(sed -n '/^Subject/ s/Subject: //p' \"$dotest/info\")\"\n+\t\t\tcase \"$keep_subject\" in -k)  SUBJECT=\"[PATCH] $SUBJECT\" ;; esac\n+\n+\t\t\t(echo \"$SUBJECT\" ; echo ; cat \"$dotest/msg\") |\n+\t\t\t\tgit stripspace > \"$dotest/msg-clean\"\n+\t\tfi\n \t\t;;\n \tesac\n \ndiff --git a/t/t3408-rebase-multi-line.sh b/t/t3408-rebase-multi-line.sh\nnew file mode 100755\nindex 0000000..e12cd57\n--- /dev/null\n+++ b/t/t3408-rebase-multi-line.sh\n@@ -0,0 +1,41 @@\n+#!/bin/sh\n+\n+test_description='rebasing a commit with multi-line first paragraph.'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+\n+\t>file &&\n+\tgit add file &&\n+\ttest_tick &&\n+\tgit commit -m initial &&\n+\n+\techo hello >file &&\n+\ttest_tick &&\n+\tgit commit -a -m \"A sample commit log message that has a long\n+summary that spills over multiple lines.\n+\n+But otherwise with a sane description.\"\n+\n+\tgit branch side &&\n+\n+\tgit reset --hard HEAD^ &&\n+\t>elif &&\n+\tgit add elif &&\n+\ttest_tick &&\n+\tgit commit -m second\n+\n+'\n+\n+test_expect_success rebase '\n+\n+\tgit checkout side &&\n+\tgit rebase master &&\n+\tgit cat-file commit HEAD | sed -e \"1,/^$/d\" >actual &&\n+\tgit cat-file commit side@{1} | sed -e \"1,/^$/d\" >expect &&\n+\ttest_cmp expect actual\n+\n+'\n+\n+test_done\n-- \n1.5.5.120.gea9a0\n"},{"id":"74581","messageId":"7vve2hpnz1.fsf@gitster.siamese.dyndns.org","threadId":"13127","inReplyTo":"alpine.LFD.1.00.0804151222350.2879@woody.linux-foundation.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2008-04-16T20:02:42Z","receivedAt":"2008-04-16T20:02:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> Ahh, looks like a git-am buglet then. It will indeed turn an empty subject \n> line into an empty first line.\n>\n> We should run \"git stripspace\" on the whole thing, so maybe a patch \n> something like the appended will help.\n>\n> NOTE! Totally untested! Beware the patch!\n\nThe basic idea is very sound and as usual your patch deletes more lines\nthan it adds, which always impresses me.  I wish all our patches are like\nthis.\n\n> @@ -388,6 +383,7 @@ do\n>  \t\t\t;;\n>  \t\tesac\n>  \tesac\n> +\tFIRSTLINE=$(head -1 \"$dotest/final-commit\")\n>  \n>  \tresume=\n>  \tif test \"$interactive\" = t\n> @@ -408,7 +404,6 @@ do\n>  \t\t[aA]*) action=yes interactive= ;;\n>  \t\t[nN]*) action=skip ;;\n>  \t\t[eE]*) git_editor \"$dotest/final-commit\"\n> -\t\t       SUBJECT=$(reread_subject \"$dotest/final-commit\")\n\nThis needs to be replaced with re-assignment to FIRSTLINE, as the user may\nhave fixed the title in the editor; otherwise...\n\n> @@ -431,7 +426,7 @@ do\n>  \t\tstop_here $this\n>  \tfi\n>  \n> -\tprintf 'Applying %s\\n' \"$SUBJECT\"\n> +\tprintf 'Applying %s\\n' \"$FIRSTLINE\"\n\n... this would surprise the user who expects us to give the report with\nthe updated title.\n"},{"id":"74590","messageId":"alpine.LFD.1.00.0804161312330.2879@woody.linux-foundation.org","threadId":"13127","inReplyTo":"7vve2hpnz1.fsf@gitster.siamese.dyndns.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-16T20:17:42Z","receivedAt":"2008-04-16T20:17:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 16 Apr 2008, Junio C Hamano wrote:\n> \n> > @@ -388,6 +383,7 @@ do\n> >  \t\t\t;;\n> >  \t\tesac\n> >  \tesac\n> > +\tFIRSTLINE=$(head -1 \"$dotest/final-commit\")\n> >  \n> >  \tresume=\n> >  \tif test \"$interactive\" = t\n> > @@ -408,7 +404,6 @@ do\n> >  \t\t[aA]*) action=yes interactive= ;;\n> >  \t\t[nN]*) action=skip ;;\n> >  \t\t[eE]*) git_editor \"$dotest/final-commit\"\n> > -\t\t       SUBJECT=$(reread_subject \"$dotest/final-commit\")\n> \n> This needs to be replaced with re-assignment to FIRSTLINE, as the user may\n> have fixed the title in the editor; otherwise...\n\nHmm. I think we could just have moved the assignment of FIRSTLINE it down, \nand had it in just one place. I see you already fixed it up, but maybe a \npatch like this is still a worthy cleanup.\n\nThat said - I didn't check that there isn't some subtle intermediate user \nor a break out of the loop or something. So while this patch _looks_ \nobvious and passes the tests, I'm not going to guarantee that there isn't \nsome special case. I doubt any of the tests really check things like the \nreflog comments after git-am etc..\n\n\t\tLinus\n\n---\n git-am.sh |    3 +--\n 1 files changed, 1 insertions(+), 2 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 245e1db..9a865cc 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -383,7 +383,6 @@ do\n \t\t\t;;\n \t\tesac\n \tesac\n-\tFIRSTLINE=$(head -1 \"$dotest/final-commit\")\n \n \tresume=\n \tif test \"$interactive\" = t\n@@ -404,7 +403,6 @@ do\n \t\t[aA]*) action=yes interactive= ;;\n \t\t[nN]*) action=skip ;;\n \t\t[eE]*) git_editor \"$dotest/final-commit\"\n-\t\t       FIRSTLINE=$(head -1 \"$dotest/final-commit\")\n \t\t       action=again ;;\n \t\t[vV]*) action=again\n \t\t       LESS=-S ${PAGER:-less} \"$dotest/patch\" ;;\n@@ -427,6 +425,7 @@ do\n \t\tstop_here $this\n \tfi\n \n+\tFIRSTLINE=$(head -1 \"$dotest/final-commit\")\n \tprintf 'Applying %s\\n' \"$FIRSTLINE\"\n \n \tcase \"$resolved\" in\n"},{"id":"74591","messageId":"200804162222.18827.jnareb@gmail.com","threadId":"13127","inReplyTo":"7v3aplr2pt.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: Re* [GIT PULL] sh updates for 2.6.25","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-16T20:22:18Z","receivedAt":"2008-04-16T20:22:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n[cut]\n\n> So in short, when you use \"am\", it by design unfolds the \"Subject: \" line\n> and there is no bug there.  \"rebase\" being implemented in terms of\n> \"format-patch piped to am\" does mangle the message because of this, but\n> if anything that is a bug in rebase, and not \"am\".\n> \n> And this is a potential fix to the issue, which was made possible only\n> because recently \"rebase\" started passing an extra option to \"am\".\n> \n> -- >8 --\n> From: Junio C Hamano <gitster@pobox.com>\n> Date: Wed, 16 Apr 2008 12:50:48 -0700\n> Subject: [PATCH] rebase: do not munge commit log message\n> \n> Traditionally git-rebase was implemented in terms of \"format-patch\" piped\n> to \"am -3\", to strike balance between speed (because it avoids a rather\n> expensive read-tree/merge-recursive machinery most of the time) and\n> flexibility (the magic \"-3\" allows it to fall back to 3-way merge as\n> necessary).  However, this combination has one flaw when dealing with a\n> nonstandard commit log message format that has more than one lines in the\n> first paragraph, because such a \"first line\" is formatted as logically a\n> single line, and unfolded at the applying end.\n> \n> This teaches \"git am --rebasing\" to take advantage of the fact that the\n> mbox message \"git rebase\" prepares for it records the original commit\n> object name, and that such a commit _is_ available locally.  It reads the\n> log message from the original commit object instead.\n\nIIRC there was alternate patch which made git-format-patch to add extra\nemail header meant for git-am to \"obey the (encoded) commit message\nformatting.\"\n\nBut this solution is simpler, and I think better.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"74683","messageId":"20080417213801.GL23696@genesis.frugalware.org","threadId":"13127","inReplyTo":"7v3aplr2pt.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: Re* [GIT PULL] sh updates for 2.6.25","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-04-17T21:38:01Z","receivedAt":"2008-04-17T21:38:01Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Wed, Apr 16, 2008 at 12:58:54PM -0700, Junio C Hamano <gitster@pobox.com> wrote:\n> When one adopts the notion of \"a single line at the top summarizes what\n> the commit is about\", it is very natural to call that a \"title\", and\n> having a blank line between the title and the body to separate them also\n> becomes natural, and it matches how a patch is presented in email, as a\n> bonus, so it matches people's expectation.\n> \n> So this format is merely a convention when viewed at the \"plumbing\" level,\n> but it is more important than just a convention if you are living at the\n> \"Porcelain\" level; if you deviate from that, \"Porcelain\" would not work\n> very well for you.\n\nI understand this, my only problem is that some project does not use an\nempty line after the \"title\". Consider a commit message like:\n\n----\nChange foo to bar\n- this patch changes foo to bar becase of baz\n- ok devel1@, devel2@\n----\n\nGiven that a project uses such a commit message style, the newlines are\nremoved when applying with git am, but the commit still has a title.\n\n> People who are used to other systems without a good history summarization\n> tools can and do write such log messages.  People who make commits on such\n> systems whose commits are imported to git (perhaps even without them\n> knowing about it) do not have an incentive to use a short-and-clear single\n> line summary in each of their commits, as their system may not give a good\n> way to make use of the result of such a practice.\n\nThat makes sense, but those commits are unlikely transferred using\nformat-patch+am. :)\n\n> These days, format-patch was taught to use \"the first paragraph\" as the\n> summarizing first line to avoid chomping a sentence in the middle.  This\n> change did not hurt people who use git \"Porcelain\", as the commit log\n> message for them is always \"a single line summary, a blank line, and the\n> body\".  The first paragraph is the same as the first line for them.  But\n> for commits that have a multi-line paragraph at the beginning, information\n> lossage is avoided this way.  Now the first chunk of the message, even if\n> it is splattered over two physical lines, is used as the summary.\n\nI see. If I'm right, then basically the old behaviour is what I want. At\nleast after a\n\ngit reset --hard 4234a76167b12a7669dae0e6386c62e712b9dcf5^\n\nI get the behaviour I wished. :)\n\n(Well, almost. It inserts a newline after the first line but that's far\nbetter than stripping all the newlines.)\n\nWould you accept a patch that would make this configurable?\n\n> So in short, when you use \"am\", it by design unfolds the \"Subject: \" line\n> and there is no bug there.  \"rebase\" being implemented in terms of\n> \"format-patch piped to am\" does mangle the message because of this, but\n> if anything that is a bug in rebase, and not \"am\".\n\nYes, that's an other issue.\n\nThanks.\n"},{"id":"75322","messageId":"1209323069.25560.88.camel@pmac.infradead.org","threadId":"13127","inReplyTo":"alpine.LFD.1.00.0804151048060.2879@woody.linux-foundation.org","subject":"Re: [GIT PULL] sh updates for 2.6.25","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2008-04-27T19:04:29Z","receivedAt":"2008-04-27T19:04:29Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Tue, 2008-04-15 at 11:01 -0700, Linus Torvalds wrote:\n> Paul, your git tree is odd. Not quite corrupt, but it doesn't really \n> follow the rules either.\n> \n> In particular, it has empty lines at the top of those commits, and I \n> wonder how you created them. \n\nHm, I noticed those go past on the commits list and meant to\ninvestigate, but got distracted before I got round to it. Should I\nassume there's nothing to fix in the script which feeds the list, then?\n\n$todo--; :)\n\n-- \ndwmw2\n"}]}