{"thread":{"id":"9273","subject":"git-svn rebase screwing up commit messages","startedAt":"2007-07-28T10:07:41Z","lastAt":"2007-07-29T19:02:21Z","messageCount":18,"participants":["Benoit SIGOURE","Junio C Hamano","Sean","Jakub Narebski","Robin Rosenberg","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48892","messageId":"724DFB31-0471-4A5E-95DF-F5F74876AC77@lrde.epita.fr","threadId":"9273","inReplyTo":null,"subject":"git-svn rebase screwing up commit messages","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-07-28T10:07:41Z","receivedAt":"2007-07-28T10:07:41Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"Hello,\ngit version 1.5.2.3 over here, I've googled and searched in the ML \narchives but did not find this: when I git-svn rebase, my commits in \nGit (that are temporarily removed and then re-applied) get their \ncommit message flattened on a single line (needless to say this is \nutterly annoying :D).\n\nIs this a bug or something?\n\nThanks.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"48897","messageId":"7v8x90sp25.fsf@assigned-by-dhcp.cox.net","threadId":"9273","inReplyTo":"724DFB31-0471-4A5E-95DF-F5F74876AC77@lrde.epita.fr","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-28T12:14:26Z","receivedAt":"2007-07-28T12:14:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Benoit SIGOURE writes:\n\n> git version 1.5.2.3 over here, I've googled and searched in the ML\n> archives but did not find this: when I git-svn rebase, my commits in\n> Git (that are temporarily removed and then re-applied) get their\n> commit message flattened on a single line...\n\nDo you mean by \"my commits in Git\" a commit you created with git\nin your git repository?\n"},{"id":"48899","messageId":"20070728083536.540e471d.seanlkml@sympatico.ca","threadId":"9273","inReplyTo":"7v8x90sp25.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-28T12:35:36Z","receivedAt":"2007-07-28T12:35:36Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 28 Jul 2007 05:14:26 -0700\nJunio C Hamano wrote:\n\nHi,\n\n> Benoit SIGOURE writes:\n> \n> > git version 1.5.2.3 over here, I've googled and searched in the ML\n> > archives but did not find this: when I git-svn rebase, my commits in\n> > Git (that are temporarily removed and then re-applied) get their\n> > commit message flattened on a single line...\n> \n> Do you mean by \"my commits in Git\" a commit you created with git\n> in your git repository?\n> \n\nTested this here (rc3.24.g83b3d) and can confirm the reported problem.\nAfter making a commit in git and then running \"git svn rebase\" to\nreceive updates from the svn repo, the rebased commit has a borked\ndescription (multi-lined commit message appears all on one line).\n\nSean\n"},{"id":"48903","messageId":"7vodhwptba.fsf@assigned-by-dhcp.cox.net","threadId":"9273","inReplyTo":"20070728083536.540e471d.seanlkml@sympatico.ca","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-28T13:10:49Z","receivedAt":"2007-07-28T13:10:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean writes:\n\n>> Do you mean by \"my commits in Git\" a commit you created with git\n>> in your git repository?\n>\n> Tested this here (rc3.24.g83b3d) and can confirm the reported problem.\n> After making a commit in git and then running \"git svn rebase\" to\n> receive updates from the svn repo, the rebased commit has a borked\n> description (multi-lined commit message appears all on one line).\n\nIn short, your original commit log message is broken.\n\nThe recommended convention for commit messages is to start it\nwith a single line that describes what it does, followed by a\nblank line (i.e. the first paragraph consists of a single line),\nfollowed by a longer explanation of why the change brought by\nthe commit is a good thing.\n\nFollowing this convention is recommended to make other peoples'\nlives more pleasant, and git assumes you follow this convention\nat several places. For example, \"git log --pretty=oneline\",\n\"git reflog\", and \"git show-branch\" are ways to get concise\nlisting of commits; git-shortlog gives the list of such commit\ntitles in its output, omitting the longer explanation. Patches\nprepared for e-mail exchange (\"git format-patch\", and\n--pretty=email) use the title on the Subject: line of the\nmessage. \n\nThe behaviour of these tools are _not_ the primarly reasons why\nyou are better off following the commit message convention. The\nreason behind the behaviour of these tools is to help readers of\nyour commit messages. The punch line comes at the beginning,\nsingle line short-and-sweet, and when readers want to get the\nbirds-eye view, that is the only thing they see.\n\nTry them on a commit that has several lines in its first\nparagraph and you will see why this is a good convention.\n\nUntil recently, we chomped a multi-line first paragraph at the\nfirst line, and used the resulting partial sentence as the\ntitle. This had an interesting effect on badly formatted commit\nlike this:\n\n tree 2a003266ee6fda9305833a4f6e6dc7194018805a\n parent fef221460121c8a1b9e242422d8b521fbd0f6dc0\n author Junio C Hamano 1185621830 -0700\n committer Junio C Hamano 1185621830 -0700\n\n A long and unsightly commit\n log message that has more than\n one lines in the first paragraph\n\n Such a first paragraph is flattened by --pretty=email\n\nWhen this was formatted for e-mail, it resulted in something\nlike this:\n\n From: Junio C Hamano \n Date: Sat, 28 Jul 2007 04:23:50 -0700\n Subject: [PATCH] A long and unsightly commit\n log message that has more than\n one lines in the first paragraph\n\n Such a first paragraph is flattened by --pretty=email\n\nAs rebase/am uses the same machinery as e-mailed patch\nacceptance, the paragraph was chomped at the first line, while\nnormalizing it for other git commands' use, like this:\n\n tree 842c159f584fd4f970b6aceed21f479c1b62e333\n parent 57887443c24e5a2b4b04e7db69b44b53d8e87b44\n author Junio C Hamano 1185621830 -0700\n committer Junio C Hamano 1185626445 -0700\n\n A long and unsightly commit\n\n log message that has more than\n one lines in the first paragraph\n\n Such a first paragraph is flattened by --pretty=email\n\nThis would mean that \"oneline\" format will see only the initial\npart of the sentence. If your message is properly formatted,\nit is not a problem.\n\nRecent enough git instead uses RFC2822 line-folding like this,\nto help noncomforming messages somewhat:\n\n From 4c04a94...\n From: Junio C Hamano \n Date: Sat, 28 Jul 2007 04:23:50 -0700\n Subject: [PATCH] A long and unsightly commit\n log message that has more than\n one lines in the first paragraph\n\n Such a first paragraph is flattened by --pretty=email\n\nBut this has an interesting side effect itself. Such a folded\nline is logically treated as a single line, and rebase/am makes\na commit like this out of such a message:\n\n tree 842c159f584fd4f970b6aceed21f479c1b62e333\n parent 57887443c24e5a2b4b04e7db69b44b53d8e87b44\n author Junio C Hamano 1185621830 -0700\n committer Junio C Hamano 1185626469 -0700\n\n A long and unsightly commit log message that has more than one lines in the first paragraph\n\n Such a first paragraph is flattened by --pretty=email\n\nwhich is still unsightly (but the original message is unfriendly\nto oneline summary format to begin with). At least, this is an\nimprovement in that the new formatting does not lose information\nwhen viewed in \"oneline\" format.\n\nHaving said all that, so that the readers understand the\nbackground, here is a not-so-heavily-tested patch, which might\nhelp. It passes all the test suite as before, but that tells\nhow existing git-svn tests do not test many things.\n\nI am not considering this for inclusion right now, by the way.\n\n-- >8 --\nRebase/am: preserve multi-line first paragraph better.\n\nThis is actually three patches folded into one; as such it\nshould not be applied as-is. It needs to be split into:\n\n * Changes to refs.c::log_ref_write() to sanitize embedded\n newlines from the log message, instead of chomping it at the\n first newline;\n\n * Changes to symbolic-ref and update-ref, so that they do not\n refuse a reflog message that has embedded newlines. They\n have no business in dictating what the reflog message should\n look like.\n\n * Changes to builtin-mailinfo.c to preserve LF in Subject:\n header, when it is folded using RFC2822 header folding.\n\nWith this, the first paragraph of a commit message that has\nmultiple lines is reproduced by \"am\" without being squashed into\na single line.\n\n---\n\n builtin-mailinfo.c | 29 +++++++++++++++++++++++------\n builtin-symbolic-ref.c | 2 --\n builtin-update-ref.c | 2 --\n refs.c | 39 +++++++++++++++++++++++----------------\n 4 files changed, 46 insertions(+), 26 deletions(-)\n\ndiff --git a/builtin-mailinfo.c b/builtin-mailinfo.c\nindex b4f6e91..9d2064a 100644\n--- a/builtin-mailinfo.c\n+++ b/builtin-mailinfo.c\n@@ -272,15 +272,15 @@ static char *cleanup_subject(char *subject)\n \t}\n }\n \n-static void cleanup_space(char *buf)\n+static void cleanup_space(char *buf, int keep_LF)\n {\n \tunsigned char c;\n \twhile ((c = *buf) != 0) {\n \t\tbuf++;\n-\t\tif (isspace(c)) {\n+\t\tif (isspace(c) && (!keep_LF || c != '\\n')) {\n \t\t\tbuf[-1] = ' ';\n \t\t\tc = *buf;\n-\t\t\twhile (isspace(c)) {\n+\t\t\twhile (isspace(c) && (!keep_LF || c != '\\n')) {\n \t\t\t\tint len = strlen(buf);\n \t\t\t\tmemmove(buf, buf+1, len);\n \t\t\t\tc = *buf;\n@@ -425,6 +425,7 @@ static int read_one_header_line(char *line, int sz, FILE *in)\n \t\t\tif (addlen >= sz - len)\n \t\t\t\taddlen = sz - len - 1;\n \t\t\tmemcpy(line + len, continuation, addlen);\n+\t\t\tline[len] = '\\n';\n \t\t\tlen += addlen;\n \t\t}\n \t}\n@@ -846,6 +847,22 @@ static void handle_body(void)\n \treturn;\n }\n \n+static void output_header_lines(FILE *fout, const char *hdr, char *data)\n+{\n+\twhile (1) {\n+\t\tchar *ep = strchr(data, '\\n');\n+\t\tint len;\n+\t\tif (!ep)\n+\t\t\tlen = strlen(data);\n+\t\telse\n+\t\t\tlen = ep - data;\n+\t\tfprintf(fout, \"%s: %.*s\\n\", hdr, len, data);\n+\t\tif (!ep)\n+\t\t\tbreak;\n+\t\tdata = ep + 1;\n+\t}\n+}\n+\n static void handle_info(void)\n {\n \tchar *sub;\n@@ -864,14 +881,14 @@ static void handle_info(void)\n \n \t\tif (!memcmp(header[i], \"Subject\", 7)) {\n \t\t\tsub = cleanup_subject(hdr);\n-\t\t\tcleanup_space(sub);\n-\t\t\tfprintf(fout, \"Subject: %s\\n\", sub);\n+\t\t\tcleanup_space(sub, 1);\n+\t\t\toutput_header_lines(fout, \"Subject\", sub);\n \t\t} else if (!memcmp(header[i], \"From\", 4)) {\n \t\t\thandle_from(hdr);\n \t\t\tfprintf(fout, \"Author: %s\\n\", name);\n \t\t\tfprintf(fout, \"Email: %s\\n\", email);\n \t\t} else {\n-\t\t\tcleanup_space(hdr);\n+\t\t\tcleanup_space(hdr, 0);\n \t\t\tfprintf(fout, \"%s: %s\\n\", header[i], hdr);\n \t\t}\n \t}\ndiff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c\nindex d41b406..9eb95e5 100644\n--- a/builtin-symbolic-ref.c\n+++ b/builtin-symbolic-ref.c\n@@ -43,8 +43,6 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)\n \t\t\tmsg = argv[1];\n \t\t\tif (!*msg)\n \t\t\t\tdie(\"Refusing to perform update with empty message\");\n-\t\t\tif (strchr(msg, '\\n'))\n-\t\t\t\tdie(\"Refusing to perform update with \\\\n in message\");\n \t\t}\n \t\telse if (!strcmp(\"--\", arg)) {\n \t\t\targc--;\ndiff --git a/builtin-update-ref.c b/builtin-update-ref.c\nindex feac2ed..8339cf1 100644\n--- a/builtin-update-ref.c\n+++ b/builtin-update-ref.c\n@@ -23,8 +23,6 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)\n \t\t\tmsg = argv[++i];\n \t\t\tif (!*msg)\n \t\t\t\tdie(\"Refusing to perform update with empty message.\");\n-\t\t\tif (strchr(msg, '\\n'))\n-\t\t\t\tdie(\"Refusing to perform update with \\\\n in message.\");\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(\"-d\", argv[i])) {\ndiff --git a/refs.c b/refs.c\nindex 2694e70..98e3202 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -1036,6 +1036,27 @@ void unlock_ref(struct ref_lock *lock)\n \tfree(lock);\n }\n \n+static int copy_msg(char *buf, const char *msg)\n+{\n+\tchar *cp = buf;\n+\tchar c;\n+\tint wasspace = 1;\n+\n+\t*cp++ = '\\t';\n+\twhile ((c = *msg++)) {\n+\t\tif (wasspace && isspace(c))\n+\t\t\tcontinue;\n+\t\twasspace = isspace(c);\n+\t\tif (wasspace)\n+\t\t\tc = ' ';\n+\t\t*cp++ = c;\n+\t}\n+\twhile (buf < cp && isspace(cp[-1]))\n+\t\tcp--;\n+\t*cp++ = '\\n';\n+\treturn cp - buf;\n+}\n+\n static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,\n \t\t\t const unsigned char *new_sha1, const char *msg)\n {\n@@ -1080,21 +1101,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,\n \n \tadjust_shared_perm(log_file);\n \n-\tmsglen = 0;\n-\tif (msg) {\n-\t\t/* clean up the message and make sure it is a single line */\n-\t\tfor ( ; *msg; msg++)\n-\t\t\tif (!isspace(*msg))\n-\t\t\t\tbreak;\n-\t\tif (*msg) {\n-\t\t\tconst char *ep = strchr(msg, '\\n');\n-\t\t\tif (ep)\n-\t\t\t\tmsglen = ep - msg;\n-\t\t\telse\n-\t\t\t\tmsglen = strlen(msg);\n-\t\t}\n-\t}\n-\n+\tmsglen = msg ? strlen(msg) : 0;\n \tcommitter = git_committer_info(-1);\n \tmaxlen = strlen(committer) + msglen + 100;\n \tlogrec = xmalloc(maxlen);\n@@ -1103,7 +1110,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,\n \t\t sha1_to_hex(new_sha1),\n \t\t committer);\n \tif (msglen)\n-\t\tlen += sprintf(logrec + len - 1, \"\\t%.*s\\n\", msglen, msg) - 1;\n+\t\tlen += copy_msg(logrec + len - 1, msg) - 1;\n \twritten = len <= maxlen ? write_in_full(logfd, logrec, len) : -1;\n \tfree(logrec);\n \tif (close(logfd) != 0 || written != len)\n"},{"id":"48904","messageId":"20070728092914.48f6305c.seanlkml@sympatico.ca","threadId":"9273","inReplyTo":"7vodhwptba.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-28T13:29:14Z","receivedAt":"2007-07-28T13:29:14Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 28 Jul 2007 06:10:49 -0700\nJunio C Hamano wrote:\n\n> In short, your original commit log message is broken.\n> \n> The recommended convention for commit messages is to start it\n> with a single line that describes what it does, followed by a\n> blank line (i.e. the first paragraph consists of a single line),\n> followed by a longer explanation of why the change brought by\n> the commit is a good thing.\n\nThat explains why I hadn't seen the problem before, since I\nusually follow the commit message convention. For testing\npurposes I had simply mashed the home row to add five or\nsix lines without thinking...\n\n> Following this convention is recommended to make other peoples'\n> lives more pleasant, and git assumes you follow this convention\n> at several places. For example, \"git log --pretty=oneline\",\n> \"git reflog\", and \"git show-branch\" are ways to get concise\n> listing of commits; git-shortlog gives the list of such commit\n> titles in its output, omitting the longer explanation. Patches\n> prepared for e-mail exchange (\"git format-patch\", and\n> --pretty=email) use the title on the Subject: line of the\n> message. \n\nYes, Bisecting shows this \"problem\" was introduced in your\ncommit 4234a76167 which mentions that commit messages following\nthe normal convention would be unaffected.\n\n...[SNIPPED]...\n> Having said all that, so that the readers understand the\n> background, here is a not-so-heavily-tested patch, which might\n> help. It passes all the test suite as before, but that tells\n> how existing git-svn tests do not test many things.\n> \n> I am not considering this for inclusion right now, by the way.\n\nFWIW your patch fixed my test case here.\n\nCheers,\nSean\n"},{"id":"48905","messageId":"7vk5skps1g.fsf@assigned-by-dhcp.cox.net","threadId":"9273","inReplyTo":"20070728092914.48f6305c.seanlkml@sympatico.ca","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-28T13:38:19Z","receivedAt":"2007-07-28T13:38:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean writes:\n\n>> Having said all that, so that the readers understand the\n>> background, here is a not-so-heavily-tested patch, which might\n>> help. It passes all the test suite as before, but that tells\n>> how existing git-svn tests do not test many things.\n>> \n>> I am not considering this for inclusion right now, by the way.\n>\n> FWIW your patch fixed my test case here.\n\nActually the patched behaviour actively encourages a bad (not in\nthe sense that those oneline tools will not work well, but in\nthe sense that these messages are reader unfriendly) practice; I\ndo not think what the patch did deserves to be called \"fixed\".\n\nAnd that is one of the reasons, other than that we are in -rc\nfreeze that we do not add anything but unarguable fixes, that I\nam not considering the patch for inclusion right now.\n"},{"id":"48906","messageId":"20070728101156.20304d11.seanlkml@sympatico.ca","threadId":"9273","inReplyTo":"7vk5skps1g.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-28T14:11:56Z","receivedAt":"2007-07-28T14:11:56Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 28 Jul 2007 06:38:19 -0700\nJunio C Hamano wrote:\n\n\n> Actually the patched behaviour actively encourages a bad (not in\n> the sense that those oneline tools will not work well, but in\n> the sense that these messages are reader unfriendly) practice; I\n> do not think what the patch did deserves to be called \"fixed\".\n> And that is one of the reasons, other than that we are in -rc\n> freeze that we do not add anything but unarguable fixes, that I\n> am not considering the patch for inclusion right now.\n> \n\nFirst, i didn't read the patch and i have no stake at all in\nnon-conforming commit messages; i always follow the convention.\nHaving said that, the current behavior of Git crosses the line\nfrom advocating the common commit message format into the realm\nof not-working properly with non-conforming commit messages.\n\nI would argue that you shouldn't try to have it both ways. Either\nGit supports non-conforming message formats, in which case the\ncurrent behavior seems buggy. Or Git does not support commit\nmessages that deviate from the standard, in which case the\ndocumentation should be updated to state so bluntly.\n\nIf handling email-mangled commit messages means that non-conforming\nformats can no longer be fully supported (while discouraged) then\nperhaps the time has come to explicitly state that people should\nnot expect Git to handle anything but the 1+empty+description\ncommit message format.\n\nSean\n"},{"id":"48909","messageId":"f8fk23$cuo$1@sea.gmane.org","threadId":"9273","inReplyTo":"7vk5skps1g.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-07-28T14:32:36Z","receivedAt":"2007-07-28T14:32:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Sean writes:\n> \n>>> Having said all that, so that the readers understand the\n>>> background, here is a not-so-heavily-tested patch, which might\n>>> help. It passes all the test suite as before, but that tells\n>>> how existing git-svn tests do not test many things.\n>>> \n>>> I am not considering this for inclusion right now, by the way.\n>>\n>> FWIW your patch fixed my test case here.\n> \n> Actually the patched behaviour actively encourages a bad (not in\n> the sense that those oneline tools will not work well, but in\n> the sense that these messages are reader unfriendly) practice; I\n> do not think what the patch did deserves to be called \"fixed\".\n> \n> And that is one of the reasons, other than that we are in -rc\n> freeze that we do not add anything but unarguable fixes, that I\n> am not considering the patch for inclusion right now.\n\nI think that git should not enforce this policy. Think import\nand exchange with foreign SCMs which do not follow this, argueably\nvery reasonable, one-line summary policy.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"48914","messageId":"9B05AC3D-F791-4489-B523-C1392E480191@lrde.epita.fr","threadId":"9273","inReplyTo":"7vodhwptba.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-07-28T17:33:40Z","receivedAt":"2007-07-28T17:33:40Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Jul 28, 2007, at 3:10 PM, Junio C Hamano wrote:\n\n> Sean writes:\n>\n>>> Do you mean by \"my commits in Git\" a commit you created with git\n>>> in your git repository?\n>>\n>> Tested this here (rc3.24.g83b3d) and can confirm the reported \n>> problem.\n>> After making a commit in git and then running \"git svn rebase\" to\n>> receive updates from the svn repo, the rebased commit has a borked\n>> description (multi-lined commit message appears all on one line).\n>\n> In short, your original commit log message is broken.\n>\n> The recommended convention for commit messages is to start it\n> with a single line that describes what it does, followed by a\n> blank line (i.e. the first paragraph consists of a single line),\n> followed by a longer explanation of why the change brought by\n> the commit is a good thing.\n>\n\nHi people,\nthanks for the quick and complete replies. As a user, I do not \nexpect git-rebase to change my commit message. I was aware of this \nconvention in Git, but it looks like it's more than just a \nconvention. This trap should either be fixed (your patch works for \nme) or it should be clearly stated in the documentation that commit \nmessages must really be formatted according to the convention.\n\nPersonally I expected Git to keep the 1st line of my commit message \nas the \"short version\" (which is what git log and the like do ATM) \nand although I don't leave a blank line between the 1st line and the \nrest of the message, the 1st line is always the sentence that can be \nused as a short version of the commit message.\n\nCheers,\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"48927","messageId":"200707282148.13751.robin.rosenberg.lists@dewire.com","threadId":"9273","inReplyTo":"7vk5skps1g.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-28T19:48:12Z","receivedAt":"2007-07-28T19:48:12Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"lördag 28 juli 2007 skrev Junio C Hamano:\n> Sean writes:\n> \n> >> Having said all that, so that the readers understand the\n> >> background, here is a not-so-heavily-tested patch, which might\n> >> help. It passes all the test suite as before, but that tells\n> >> how existing git-svn tests do not test many things.\n> >> \n> >> I am not considering this for inclusion right now, by the way.\n> >\n> > FWIW your patch fixed my test case here.\n> \n> Actually the patched behaviour actively encourages a bad (not in\n> the sense that those oneline tools will not work well, but in\n> the sense that these messages are reader unfriendly) practice; I\n> do not think what the patch did deserves to be called \"fixed\".\n\ngit-svn should not enforce git conventions when managing commits\nintended for svn. Those commits should obviously follow the conventions\nfor the target (svn) repo. \n\n-- robin\n"},{"id":"48936","messageId":"7vd4ycp8ff.fsf@assigned-by-dhcp.cox.net","threadId":"9273","inReplyTo":"20070728101156.20304d11.seanlkml@sympatico.ca","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-28T20:41:56Z","receivedAt":"2007-07-28T20:41:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean writes:\n\n> I would argue that you shouldn't try to have it both ways.\n\nYou cannot have it both ways as-is, but this is solvable. The\ninvocation of am from rebase needs an extra (internal to\nimplementation) option to use the code it patches, and the\nregular am can fold what are found on Subject: lines it used\nto.\n\nThe patch as-is breaks the more important case of e-mail\nacceptance codepath, because MUAs are free to fold the Subject:\nline when the original line is long, and what the user (the\noriginal patch submitter) expects to happen is that a\nsingle-line-ness of the original Subject: of the message to be\nkept. The patch breaks such a line at the place MUA happens to\nfold such a long, single line, for comforming messages.\n \n"},{"id":"48942","messageId":"7vzm1gnhin.fsf@assigned-by-dhcp.cox.net","threadId":"9273","inReplyTo":"7vd4ycp8ff.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn rebase screwing up commit messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-29T01:08:32Z","receivedAt":"2007-07-29T01:08:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Sean writes:\n>\n>> I would argue that you shouldn't try to have it both ways.\n>\n> You cannot have it both ways as-is, but this is solvable. The\n> invocation of am from rebase needs an extra (internal to\n> implementation) option to use the code it patches, and the\n> regular am can fold what are found on Subject: lines it used\n> to.\n>\n> The patch as-is breaks the more important case of e-mail\n> acceptance codepath, because MUAs are free to fold the Subject:\n> line when the original line is long, and what the user (the\n> original patch submitter) expects to happen is that a\n> single-line-ness of the original Subject: of the message to be\n> kept. The patch breaks such a line at the place MUA happens to\n> fold such a long, single line, for comforming messages.\n\nSo here comes an updated series, properly split along the\nlogical lines.\n\n 0001-log_ref_write-do-not-chomp-reflog-message-at-the.txt\n 0002-symbolic-ref-update-ref-do-not-refuse-reflog-message.txt\n 0003-rebase-try-not-to-munge-commit-log-message.txt\n\nI am not absolutely sure about the implications of mailinfo\nchange. I tried to be careful by making sure that:\n\n - the updated code kicks in when \"format-patch piped to am\"\n toolchain uses the -k option on both ends, as rebase/am\n does. This is the case where we would want to keep the\n way original commit log message was formatted.\n\n - otherwise the original \"line folding\" clean-up is used, so\n that usual e-mailed patch acceptance codepath cleanses the\n oneline summary obtained from the \"Subject:\" header.\n\nBecause it would be a serious regression to break the latter,\nwhile the former is just \"an improvement\" [*1], somebody really\nshould double check the change for me.\n\n[Footnote]\n\n*1* It does not mean that improved support for foreign SCM\ninteroperation does not matter. It is \"merely an improvement\"\nin the sense that people do not like what the code currently\ndoes anyway, and if the updated code is still not liked, then\nnot having such \"an improvement\" does not matter.\n"},{"id":"48943","messageId":"7vvec4nhfk.fsf_-_@assigned-by-dhcp.cox.net","threadId":"9273","inReplyTo":"7vzm1gnhin.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH 1/3] log_ref_write() -- do not chomp reflog message at the first LF","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-29T01:10:23Z","receivedAt":"2007-07-29T01:10:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A reflog file is organized as one-line-per-entry records, and we\nenforced the file format integrity by chomping the given message\nat the first LF. This changes it to convert them to SP, which\nis more in line with the --pretty=oneline format.\n\nSigned-off-by: Junio C Hamano \n---\n refs.c | 44 ++++++++++++++++++++++++++++----------------\n 1 files changed, 28 insertions(+), 16 deletions(-)\n\ndiff --git a/refs.c b/refs.c\nindex 2694e70..fac6548 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -1036,6 +1036,32 @@ void unlock_ref(struct ref_lock *lock)\n \tfree(lock);\n }\n \n+/*\n+ * copy the reflog message msg to buf, which has been allocated sufficiently\n+ * large, while cleaning up the whitespaces. Especially, convert LF to space,\n+ * because reflog file is one line per entry.\n+ */\n+static int copy_msg(char *buf, const char *msg)\n+{\n+\tchar *cp = buf;\n+\tchar c;\n+\tint wasspace = 1;\n+\n+\t*cp++ = '\\t';\n+\twhile ((c = *msg++)) {\n+\t\tif (wasspace && isspace(c))\n+\t\t\tcontinue;\n+\t\twasspace = isspace(c);\n+\t\tif (wasspace)\n+\t\t\tc = ' ';\n+\t\t*cp++ = c;\n+\t}\n+\twhile (buf < cp && isspace(cp[-1]))\n+\t\tcp--;\n+\t*cp++ = '\\n';\n+\treturn cp - buf;\n+}\n+\n static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,\n \t\t\t const unsigned char *new_sha1, const char *msg)\n {\n@@ -1080,21 +1106,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,\n \n \tadjust_shared_perm(log_file);\n \n-\tmsglen = 0;\n-\tif (msg) {\n-\t\t/* clean up the message and make sure it is a single line */\n-\t\tfor ( ; *msg; msg++)\n-\t\t\tif (!isspace(*msg))\n-\t\t\t\tbreak;\n-\t\tif (*msg) {\n-\t\t\tconst char *ep = strchr(msg, '\\n');\n-\t\t\tif (ep)\n-\t\t\t\tmsglen = ep - msg;\n-\t\t\telse\n-\t\t\t\tmsglen = strlen(msg);\n-\t\t}\n-\t}\n-\n+\tmsglen = msg ? strlen(msg) : 0;\n \tcommitter = git_committer_info(-1);\n \tmaxlen = strlen(committer) + msglen + 100;\n \tlogrec = xmalloc(maxlen);\n@@ -1103,7 +1115,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,\n \t\t sha1_to_hex(new_sha1),\n \t\t committer);\n \tif (msglen)\n-\t\tlen += sprintf(logrec + len - 1, \"\\t%.*s\\n\", msglen, msg) - 1;\n+\t\tlen += copy_msg(logrec + len - 1, msg) - 1;\n \twritten = len <= maxlen ? write_in_full(logfd, logrec, len) : -1;\n \tfree(logrec);\n \tif (close(logfd) != 0 || written != len)\n-- \n1.5.3.rc3.24.g83b3d\n"},{"id":"48944","messageId":"7vps2cnhes.fsf_-_@assigned-by-dhcp.cox.net","threadId":"9273","inReplyTo":"7vzm1gnhin.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH 2/3] symbolic-ref, update-ref: do not refuse reflog message with LF","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-29T01:10:51Z","receivedAt":"2007-07-29T01:10:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Earlier these tools refused to create a reflog entry when the\nmessage given by the calling Porcelain had a LF in it, partially\nto keep the file format integrity of reflog file, which is\none-entry-per-line. These tools should not be dictating such a\npolicy.\n\nInstead, let the codepath to write out the reflog entry worry\nabout the format integrity and allow messages with LF in them.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-symbolic-ref.c | 2 --\n builtin-update-ref.c | 2 --\n 2 files changed, 0 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c\nindex d41b406..9eb95e5 100644\n--- a/builtin-symbolic-ref.c\n+++ b/builtin-symbolic-ref.c\n@@ -43,8 +43,6 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)\n \t\t\tmsg = argv[1];\n \t\t\tif (!*msg)\n \t\t\t\tdie(\"Refusing to perform update with empty message\");\n-\t\t\tif (strchr(msg, '\\n'))\n-\t\t\t\tdie(\"Refusing to perform update with \\\\n in message\");\n \t\t}\n \t\telse if (!strcmp(\"--\", arg)) {\n \t\t\targc--;\ndiff --git a/builtin-update-ref.c b/builtin-update-ref.c\nindex feac2ed..8339cf1 100644\n--- a/builtin-update-ref.c\n+++ b/builtin-update-ref.c\n@@ -23,8 +23,6 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)\n \t\t\tmsg = argv[++i];\n \t\t\tif (!*msg)\n \t\t\t\tdie(\"Refusing to perform update with empty message.\");\n-\t\t\tif (strchr(msg, '\\n'))\n-\t\t\t\tdie(\"Refusing to perform update with \\\\n in message.\");\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(\"-d\", argv[i])) {\n-- \n1.5.3.rc3.24.g83b3d\n"},{"id":"48945","messageId":"7vlkd0nheg.fsf_-_@assigned-by-dhcp.cox.net","threadId":"9273","inReplyTo":"7vzm1gnhin.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH 3/3] rebase: try not to munge commit log message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-29T01:11:03Z","receivedAt":"2007-07-29T01:11:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This makes rebase/am keep the original commit log message\nbetter, even when it does not conform to \"single line paragraph\nto say what it does, then explain and defend why it is a good\nchange in later paragraphs\" convention.\n\nThis change is a two-edged sword. While the earlier behaviour\nwould make such commit log messages more friendly to readers who\nexpect to get the birds-eye view with oneline summary formats,\nusers who primarily use git as a way to interact with foreign\nSCM systems would not care much about the convenience of oneline\ngit log tools, but care more about preserving their own\nconvention. This changes their commits less useful to readers\nwho read them with git tools while keeping them more consistent\nwith the foreign SCM systems they interact with.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-mailinfo.c | 29 +++++++++++++++++++++----\n t/t3405-rebase-malformed.sh | 48 +++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 72 insertions(+), 5 deletions(-)\n create mode 100755 t/t3405-rebase-malformed.sh\n\ndiff --git a/builtin-mailinfo.c b/builtin-mailinfo.c\nindex b4f6e91..b558754 100644\n--- a/builtin-mailinfo.c\n+++ b/builtin-mailinfo.c\n@@ -237,8 +237,6 @@ static int eatspace(char *line)\n \n static char *cleanup_subject(char *subject)\n {\n-\tif (keep_subject)\n-\t\treturn subject;\n \tfor (;;) {\n \t\tchar *p;\n \t\tint len, remove;\n@@ -425,6 +423,7 @@ static int read_one_header_line(char *line, int sz, FILE *in)\n \t\t\tif (addlen >= sz - len)\n \t\t\t\taddlen = sz - len - 1;\n \t\t\tmemcpy(line + len, continuation, addlen);\n+\t\t\tline[len] = '\\n';\n \t\t\tlen += addlen;\n \t\t}\n \t}\n@@ -846,6 +845,22 @@ static void handle_body(void)\n \treturn;\n }\n \n+static void output_header_lines(FILE *fout, const char *hdr, char *data)\n+{\n+\twhile (1) {\n+\t\tchar *ep = strchr(data, '\\n');\n+\t\tint len;\n+\t\tif (!ep)\n+\t\t\tlen = strlen(data);\n+\t\telse\n+\t\t\tlen = ep - data;\n+\t\tfprintf(fout, \"%s: %.*s\\n\", hdr, len, data);\n+\t\tif (!ep)\n+\t\t\tbreak;\n+\t\tdata = ep + 1;\n+\t}\n+}\n+\n static void handle_info(void)\n {\n \tchar *sub;\n@@ -863,9 +878,13 @@ static void handle_info(void)\n \t\t\tcontinue;\n \n \t\tif (!memcmp(header[i], \"Subject\", 7)) {\n-\t\t\tsub = cleanup_subject(hdr);\n-\t\t\tcleanup_space(sub);\n-\t\t\tfprintf(fout, \"Subject: %s\\n\", sub);\n+\t\t\tif (keep_subject)\n+\t\t\t\tsub = hdr;\n+\t\t\telse {\n+\t\t\t\tsub = cleanup_subject(hdr);\n+\t\t\t\tcleanup_space(sub);\n+\t\t\t}\n+\t\t\toutput_header_lines(fout, \"Subject\", sub);\n \t\t} else if (!memcmp(header[i], \"From\", 4)) {\n \t\t\thandle_from(hdr);\n \t\t\tfprintf(fout, \"Author: %s\\n\", name);\ndiff --git a/t/t3405-rebase-malformed.sh b/t/t3405-rebase-malformed.sh\nnew file mode 100755\nindex 0000000..e4e2e64\n--- /dev/null\n+++ b/t/t3405-rebase-malformed.sh\n@@ -0,0 +1,48 @@\n+#!/bin/sh\n+\n+test_description='rebase should not insist on git message convention'\n+\n+. ./test-lib.sh\n+\n+cat >F <<\\EOF\n+This is an example of a commit log message\n+that does not conform to git commit convention.\n+\n+It has two paragraphs, but its first paragraph is not friendly\n+to oneline summary format.\n+EOF\n+\n+test_expect_success setup '\n+\n+\t>file1 &&\n+\t>file2 &&\n+\tgit add file1 file2 &&\n+\ttest_tick &&\n+\tgit commit -m \"Initial commit\" &&\n+\n+\tgit checkout -b side &&\n+\tcat F >file2 &&\n+\tgit add file2 &&\n+\ttest_tick &&\n+\tgit commit -F F &&\n+\n+\tgit cat-file commit HEAD | sed -e \"1,/^\\$/d\" >F0 &&\n+\n+\tgit checkout master &&\n+\n+\techo One >file1 &&\n+\ttest_tick &&\n+\tgit add file1 &&\n+\tgit commit -m \"Second commit\"\n+'\n+\n+test_expect_success rebase '\n+\n+\tgit rebase master side &&\n+\tgit cat-file commit HEAD | sed -e \"1,/^\\$/d\" >F1 &&\n+\n+\tdiff -u F0 F1 &&\n+\tdiff -u F F0\n+'\n+\n+test_done\n-- \n1.5.3.rc3.24.g83b3d\n"},{"id":"48980","messageId":"Pine.LNX.4.64.0707291248560.14781@racer.site","threadId":"9273","inReplyTo":"7vvec4nhfk.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/3] log_ref_write() -- do not chomp reflog message at the first LF","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-29T11:57:09Z","receivedAt":"2007-07-29T11:57:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 28 Jul 2007, Junio C Hamano wrote:\n\n> A reflog file is organized as one-line-per-entry records, and we\n> enforced the file format integrity by chomping the given message\n> at the first LF. This changes it to convert them to SP, which\n> is more in line with the --pretty=oneline format.\n\nWould it not be better to chop off before the first \"\\n\", and just append \n\"...\"? IOW something like\n\n-- snip --\n refs.c | 13 +++++++++----\n 1 files changed, 9 insertions(+), 4 deletions(-)\n\ndiff --git a/refs.c b/refs.c\nindex 2694e70..554436b 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -1043,7 +1043,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,\n \tunsigned maxlen, len;\n \tint msglen;\n \tchar *log_file, *logrec;\n-\tconst char *committer;\n+\tconst char *committer, *postmsg;\n \n \tif (log_all_ref_updates < 0)\n \t\tlog_all_ref_updates = !is_bare_repository();\n@@ -1088,15 +1088,16 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,\n \t\t\t\tbreak;\n \t\tif (*msg) {\n \t\t\tconst char *ep = strchr(msg, '\\n');\n-\t\t\tif (ep)\n+\t\t\tif (ep) {\n \t\t\t\tmsglen = ep - msg;\n-\t\t\telse\n+\t\t\t\tpostmsg = (ep[1] && !isspace(ep[1])) ? \"...\" : NULL;\n+\t\t\t} else\n \t\t\t\tmsglen = strlen(msg);\n \t\t}\n \t}\n \n \tcommitter = git_committer_info(-1);\n-\tmaxlen = strlen(committer) + msglen + 100;\n+\tmaxlen = strlen(committer) + msglen + 100 + 3;\n \tlogrec = xmalloc(maxlen);\n \tlen = sprintf(logrec, \"%s %s %s\\n\",\n \t\t sha1_to_hex(old_sha1),\n@@ -1104,6 +1105,10 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,\n \t\t committer);\n \tif (msglen)\n \t\tlen += sprintf(logrec + len - 1, \"\\t%.*s\\n\", msglen, msg) - 1;\n+\tif (postmsg) {\n+\t\tlen += strlen(postmsg);\n+\t\tstrcat(logrec + len - 1, postmsg);\n+\t}\n \twritten = len <= maxlen ? write_in_full(logfd, logrec, len) : -1;\n \tfree(logrec);\n \tif (close(logfd) != 0 || written != len)\n-- snap --\n\nIt is not like the reflog messages have to be very verbose; they only have \nto give a hint what the commit was about, and the commit name is the \nimportant information.\n\nWhat do you think?\n\nCiao,\nDscho\n"},{"id":"49004","messageId":"7vsl77m4i1.fsf@assigned-by-dhcp.cox.net","threadId":"9273","inReplyTo":"Pine.LNX.4.64.0707291248560.14781@racer.site","subject":"Re: [PATCH 1/3] log_ref_write() -- do not chomp reflog message at the first LF","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-29T18:47:18Z","receivedAt":"2007-07-29T18:47:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> It is not like the reflog messages have to be very verbose; they only have \n> to give a hint what the commit was about, and the commit name is the \n> important information.\n\nI've considered it, but decided against it because:\n\n (1) I did not like the information lossage;\n\n (2) this is solely to help log messages coming from outside the\n recommended convention, and having excess will not hurt the\n normal usage;\n\n (3) it is not known if messages from outside the recommended\n convention have enough information on its first line of the\n first paragraph; the result of s/\\n.*/.../ may not be\n sufficient \"hint\";\n\n (4) log output are by default piped to \"less -S\" so extra\n output gives the user chance to inspect more if he chosses\n to, without hurting the end user display; and\n\n (5) the code was simpler and less error prone to go wrong.\n"},{"id":"49005","messageId":"Pine.LNX.4.64.0707292001580.14781@racer.site","threadId":"9273","inReplyTo":"7vsl77m4i1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/3] log_ref_write() -- do not chomp reflog message at the first LF","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-29T19:02:21Z","receivedAt":"2007-07-29T19:02:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 29 Jul 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > It is not like the reflog messages have to be very verbose; they only have \n> > to give a hint what the commit was about, and the commit name is the \n> > important information.\n> \n> I've considered it, but decided against it because:\n> \n> (1) I did not like the information lossage;\n> \n> (2) this is solely to help log messages coming from outside the\n> recommended convention, and having excess will not hurt the\n> normal usage;\n> \n> (3) it is not known if messages from outside the recommended\n> convention have enough information on its first line of the\n> first paragraph; the result of s/\\n.*/.../ may not be\n> sufficient \"hint\";\n\nGood catch. Didn't think of that.\n\nCiao,\nDscho\n"}]}