{"thread":{"id":"4472","subject":"git-applymbox broken?","startedAt":"2006-06-11T22:40:24Z","lastAt":"2006-06-13T03:41:54Z","messageCount":13,"participants":["Linus Torvalds","Eric W. Biederman","Johannes Schindelin","Randy.Dunlap","Ryan Anderson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21613","messageId":"Pine.LNX.4.64.0606111535310.5498@g5.osdl.org","threadId":"4472","inReplyTo":null,"subject":"git-applymbox broken?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-11T22:40:24Z","receivedAt":"2006-06-11T22:40:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nIt looks like something has broken git-applymbox lately.\n\nThe \"From: authorname\" lines are no longer removed from the message, and \nare duplicated in the commit log. This has resulted in several recent \nkernel commits looking like this:\n\n\tcommit c0bbbc73d58f1b774cd987b5687a478a027f137c\n\tAuthor: Christoph Lameter \n\tDate: Sun Jun 11 15:22:26 2006 -0700\n\t\n\t [PATCH] typo in vmscan.c\n\t \n\t From: Christoph Lameter \n\t \n\t Looks like a comma was left from the conversion from a struct to an\n\t assignment.\n\t \n\t Signed-off-by: Christoph Lameter \n\t Signed-off-by: Andrew Morton \n\t Signed-off-by: Linus Torvalds \n\nwhere that \"From:\" in the body is totally wrong. I just didn't notice, \nuntil now. Arrr!\n\nI _suspect_ that this is the work by Eric Biederman, ie part of the \npatches that do \"Allow in body headers beyond the in body header \nprefix.\" and \"Refactor commit messge handling.\"\n\nEric? Can you please fix this up? Lines from the body of the email that \nhave been used to set authorship should _not_ also show up in the commit \nmessage.\n\n\t\tLinus\n"},{"id":"21615","messageId":"m1wtbn468o.fsf@ebiederm.dsl.xmission.com","threadId":"4472","inReplyTo":"Pine.LNX.4.64.0606111535310.5498@g5.osdl.org","subject":"Re: git-applymbox broken?","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2006-06-11T23:33:59Z","receivedAt":"2006-06-11T23:33:59Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> It looks like something has broken git-applymbox lately.\n>\n> The \"From: authorname\" lines are no longer removed from the message, and \n> are duplicated in the commit log. This has resulted in several recent \n> kernel commits looking like this:\n\nAgreed. That isn't terribly desirable.\nDo you have the original email message some place?\n\nThere is an odd case where if someone put the From: header\nin the middle of the text that we now notice and process and I\ndidn't feel right about removing a line from the middle of the\ntext.\n\nI was fixing a nasty corner case that happens if there aren't any\nmail headers at all passed to git-mailinfo. Where we could drop\nlines without processing them at all.\n\nThis doesn't look like the From: header was in the middle of the\nmessage until it was imported into git so it is probably a small\nlogic error that is easily corrected. But I need to see what\nwe are parsing so I can understand what is happening.\n\n\n> \tcommit c0bbbc73d58f1b774cd987b5687a478a027f137c\n> \tAuthor: Christoph Lameter \n> \tDate: Sun Jun 11 15:22:26 2006 -0700\n> \t\n> \t [PATCH] typo in vmscan.c\n> \t \n> \t From: Christoph Lameter \n> \t \n> \t Looks like a comma was left from the conversion from a struct to an\n> \t assignment.\n> \t \n> \t Signed-off-by: Christoph Lameter \n> \t Signed-off-by: Andrew Morton \n> \t Signed-off-by: Linus Torvalds \n>\n> where that \"From:\" in the body is totally wrong. I just didn't notice, \n> until now. Arrr!\n>\n> I _suspect_ that this is the work by Eric Biederman, ie part of the \n> patches that do \"Allow in body headers beyond the in body header \n> prefix.\" and \"Refactor commit messge handling.\"\n>\n> Eric? Can you please fix this up? Lines from the body of the email that \n> have been used to set authorship should _not_ also show up in the commit \n> message.\n\nEven if the header lines are in the middle of the body?\n\nEric\n"},{"id":"21619","messageId":"Pine.LNX.4.64.0606111735440.5498@g5.osdl.org","threadId":"4472","inReplyTo":"m1wtbn468o.fsf@ebiederm.dsl.xmission.com","subject":"Re: git-applymbox broken?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-12T00:37:47Z","receivedAt":"2006-06-12T00:37:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 11 Jun 2006, Eric W. Biederman wrote:\n> \n> This doesn't look like the From: header was in the middle of the\n> message until it was imported into git so it is probably a small\n> logic error that is easily corrected. But I need to see what\n> we are parsing so I can understand what is happening.\n\nNo, it's at the top of the body, although there might have been an empty \nline or two (ie whitespace only) before it.\n\n> Even if the header lines are in the middle of the body?\n\nWhat do you mean by \"middle\"?\n\nNo, it should only look at From: and Subject: lines if they are at the \nvery top, with no other non-whitespace lines above them. But when it looks \nat them and uses the data from them, it should then remove them from the \nbody - they are \"conceptually\" just extended header lines that just \nhappened to technically (from an rfc822 standpoint) be in the body of the \nemail.\n\n\t\tLinus\n"},{"id":"21634","messageId":"m1fyia967t.fsf@ebiederm.dsl.xmission.com","threadId":"4472","inReplyTo":"Pine.LNX.4.64.0606111735440.5498@g5.osdl.org","subject":"Re: git-applymbox broken?","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2006-06-12T07:35:34Z","receivedAt":"2006-06-12T07:35:34Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 11 Jun 2006, Eric W. Biederman wrote:\n>> \n>> This doesn't look like the From: header was in the middle of the\n>> message until it was imported into git so it is probably a small\n>> logic error that is easily corrected. But I need to see what\n>> we are parsing so I can understand what is happening.\n>\n> No, it's at the top of the body, although there might have been an empty \n> line or two (ie whitespace only) before it.\n\nOk. I'm not certain why we would not be ignoring blank lines that\nwe used to skip. The untested patch below should ensure we always\nskip those lines.\n\n\n>> Even if the header lines are in the middle of the body?\n>\n> What do you mean by \"middle\"?\n>\n> No, it should only look at From: and Subject: lines if they are at the \n> very top, with no other non-whitespace lines above them. But when it looks \n> at them and uses the data from them, it should then remove them from the \n> body - they are \"conceptually\" just extended header lines that just \n> happened to technically (from an rfc822 standpoint) be in the body of the \n> email.\n\nThis is a separate conversation and once the problem of not ignoring leading\nblank lines is fixed I will be happy to address it.\n\nEric\n\ndiff --git a/mailinfo.c b/mailinfo.c\nindex 5b6c215..72c5454 100644\n--- a/mailinfo.c\n+++ b/mailinfo.c\n@@ -279,6 +279,14 @@ static void handle_inbody_header(int *se\n return;\n }\n }\n+ /* Ignore leading blank lines */\n+ if (!(*seen & SEEN_PREFIX)) {\n+ char *ch;\n+ for (ch = line; isspace(*ch); ch++)\n+ ;\n+ if (*ch == '\\0')\n+ return;\n+ }\n *seen |= SEEN_PREFIX;\n }\n"},{"id":"21664","messageId":"m17j3m6wmw.fsf_-_@ebiederm.dsl.xmission.com","threadId":"4472","inReplyTo":"Pine.LNX.4.64.0606111735440.5498@g5.osdl.org","subject":"[PATCH] Ignore blank lines among this inbody headers.","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2006-06-12T18:45:27Z","receivedAt":"2006-06-12T18:45:27Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"\nThis is a fix for a regression introduced in:\n8b4525fb3c6d79bd3a64b8f441237a4095db4e22.\n\nWhen I refactored the inbody header parsing into a state machine I failed\nto see the logic that skipped multiple leading spaces if they are present.\nI think I assumed that logic was just there to skip the initial blank\nline between the mail headers and the body.\n\nThis restores that behaviour and since we ignore all leading blank lines\nin commit messages now this code removes the special case for the blank\nline between the mail headers and the body.\n---\n mailinfo.c | 24 ++++++++++++++++--------\n 1 files changed, 16 insertions(+), 8 deletions(-)\n\ndiff --git a/mailinfo.c b/mailinfo.c\nindex 5b6c215..3696d61 100644\n--- a/mailinfo.c\n+++ b/mailinfo.c\n@@ -229,6 +229,14 @@ static int is_multipart_boundary(const c\n \treturn (!memcmp(line, multipart_boundary, multipart_boundary_len));\n }\n \n+static int is_blank(char *line)\n+{\n+\tchar *ch;\n+\tfor (ch = line; isspace(*ch); ch++)\n+\t\t;\n+\treturn *ch == '\\0';\n+}\n+\n static int eatspace(char *line)\n {\n \tint len = strlen(line);\n@@ -243,7 +251,7 @@ #define SEEN_SUBJECT 04\n #define SEEN_BOGUS_UNIX_FROM 010\n #define SEEN_PREFIX 020\n \n-/* First lines of body can have From:, Date:, and Subject: */\n+/* First lines of body can have From:, Date:, and Subject: or be blank */\n static void handle_inbody_header(int *seen, char *line)\n {\n \tif (!memcmp(\">From\", line, 5) && isspace(line[5])) {\n@@ -279,6 +287,10 @@ static void handle_inbody_header(int *se\n \t\t\treturn;\n \t\t}\n \t}\n+\tif (isspace(line[0])) {\n+\t\tif (!(*seen & SEEN_PREFIX) && is_blank(line))\n+\t\t\treturn;\n+\t}\n \t*seen |= SEEN_PREFIX;\n }\n \n@@ -420,9 +432,7 @@ static int read_one_header_line(char *li\n \t\tif (fgets(line + ofs, sz - ofs, in) == NULL)\n \t\t\tbreak;\n \t\tlen = eatspace(line + ofs);\n-\t\tif (len == 0)\n-\t\t\tbreak;\n-\t\tif (!is_rfc2822_header(line)) {\n+\t\tif ((len == 0) || !is_rfc2822_header(line)) {\n \t\t\t/* Re-add the newline */\n \t\t\tline[ofs + len] = '\\n';\n \t\t\tline[ofs + len + 1] = '\\0';\n@@ -762,10 +772,8 @@ static void handle_body(void)\n {\n \tint seen = 0;\n \n-\tif (line[0] || fgets(line, sizeof(line), stdin) != NULL) {\n-\t\thandle_commit_msg(&seen);\n-\t\thandle_patch();\n-\t}\n+\thandle_commit_msg(&seen);\n+\thandle_patch();\n \tfclose(patchfile);\n \tif (!patch_lines) {\n \t\tfprintf(stderr, \"No patch found\\n\");\n-- \n1.4.0.rc2.g5e3a6\n"},{"id":"21665","messageId":"m13bea6w13.fsf@ebiederm.dsl.xmission.com","threadId":"4472","inReplyTo":"Pine.LNX.4.64.0606111735440.5498@g5.osdl.org","subject":"Re: git-applymbox broken?","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2006-06-12T18:58:32Z","receivedAt":"2006-06-12T18:58:32Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> What do you mean by \"middle\"?\n>\n> No, it should only look at From: and Subject: lines if they are at the \n> very top, with no other non-whitespace lines above them. But when it looks \n> at them and uses the data from them, it should then remove them from the \n> body - they are \"conceptually\" just extended header lines that just \n> happened to technically (from an rfc822 standpoint) be in the body of the \n> email.\n\nBelow is an example of the kind of patch that inspired me to relax the\nrules on parsing in body headers (this comes from Andi Kleen quilt tree).\n\nThe first line in this instance is obviously a subject line but there\nis not really good way to detect that. Then we get a From: line.\n\nNow I doubt any patches ever hit the mail in this format and it probably\nisn't worth it to track down every variation of patch headers in existence.\nBut if we don't find a From: header in the body prefix it seems to make\nsense to keep looking for headers in the body, and to use the information\nif we find it.\n\n---\nKdump i386 nmi event notification fix\n\nFrom: Vivek Goyal \n\nAfter a crash we should wait for NMI IPI event and not for external NMI or\nNMI watchdog tick.\n\nSigned-off-by: Vivek Goyal \nSigned-off-by: Andi Kleen \nCc: Don Zickus \nCc: Andi Kleen \nSigned-off-by: Andrew Morton \n---\n\n arch/i386/kernel/crash.c | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\nIndex: linux/arch/i386/kernel/crash.c\n===================================================================\n--- linux.orig/arch/i386/kernel/crash.c\n+++ linux/arch/i386/kernel/crash.c\n@@ -102,7 +102,7 @@ static int crash_nmi_callback(struct not\n \tstruct pt_regs fixed_regs;\n \tint cpu;\n \n-\tif (val != DIE_NMI)\n+\tif (val != DIE_NMI_IPI)\n \t\treturn NOTIFY_OK;\n \n \tregs = ((struct die_args *)data)->regs;\n@@ -113,7 +113,7 @@ static int crash_nmi_callback(struct not\n \t * an NMI if system was initially booted with nmi_watchdog parameter.\n \t */\n \tif (cpu == crashing_cpu)\n-\t\treturn 1;\n+\t\treturn NOTIFY_STOP;\n \tlocal_irq_disable();\n \n \tif (!user_mode_vm(regs)) {\n"},{"id":"21670","messageId":"Pine.LNX.4.64.0606121204220.5498@g5.osdl.org","threadId":"4472","inReplyTo":"m13bea6w13.fsf@ebiederm.dsl.xmission.com","subject":"Re: git-applymbox broken?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-12T19:10:27Z","receivedAt":"2006-06-12T19:10:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 12 Jun 2006, Eric W. Biederman wrote:\n> \n> Below is an example of the kind of patch that inspired me to relax the\n> rules on parsing in body headers (this comes from Andi Kleen quilt tree).\n\nAnd this is wrong.\n\nWe should _not_ accept crappy patches, and then start guessing at what the \nperson meant.\n\n>From the very beginning of git, I tried to make it extremely clear that \nthere is never any guessing going on. We don't use \"heuristics\" except as \na pure optimization: ie a heuristic can have a _performance_ impact, but \nit must never EVER have semantic impact.\n\nSCM's are not about guessing. They are about saving the _exact_ state that \nthe user asked for. No \"let's try to be nice\", no gray areas.\n\nIf the new git-applymbox just takes random lines from the body of the \nemail, and decides that they may be authorship information, then that is a \nBUG. The \"From: \" line in the middle of an email may well be about \nsomebody having _discovered_ the bug, and we're quoting him as part of the \nexplanation. It does NOT mean that it's about authorship.\n\nSo we should ONLY check for \"From:\" (and perhaps \"Subject:\" and \"Date:\") \nat the very top of the email body. NOWHERE ELSE.\n\nThe fact that somebody has a crappy quilt tree, and the fact that quilt is \nvery much a \"anything goes\" kind of laissez faire system does not mean, \nand should NEVER mean that git becomes the same kind of mess of \"let's do \na best effort and try to guess what somebody means\" kind of thing.\n\nI check and edit my emails before I apply them, and I try to teach the \npeople who send them manners and what the rules are. THAT is the way to \nhandle this, not by having the tool itself become unreliable and random\n\n\t\tLinus\n"},{"id":"21675","messageId":"m1odwy5g0b.fsf_-_@ebiederm.dsl.xmission.com","threadId":"4472","inReplyTo":"m17j3m6wmw.fsf_-_@ebiederm.dsl.xmission.com","subject":"[PATCH] Ignore blank lines among this inbody headers","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2006-06-12T19:29:56Z","receivedAt":"2006-06-12T19:29:56Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"\nThis is a fix for a regression introduced in:\n8b4525fb3c6d79bd3a64b8f441237a4095db4e22.\n\nWhen I refactored the inbody header parsing into a state machine I failed\nto see the logic that skipped multiple leading spaces if they are present.\nI think I assumed that logic was just there to skip the initial blank\nline between the mail headers and the body.\n\nThis restores that behaviour and since we ignore all leading blank lines\nin commit messages now this code removes the special case for the blank\nline between the mail headers and the body.\n\nSigned-off-by: Eric W. Biederman \n---\n\nThis is a resend to add my missing Signed-off-by line.\n---\n mailinfo.c | 24 ++++++++++++++++--------\n 1 files changed, 16 insertions(+), 8 deletions(-)\n\ndiff --git a/mailinfo.c b/mailinfo.c\nindex 5b6c215..3696d61 100644\n--- a/mailinfo.c\n+++ b/mailinfo.c\n@@ -229,6 +229,14 @@ static int is_multipart_boundary(const c\n \treturn (!memcmp(line, multipart_boundary, multipart_boundary_len));\n }\n \n+static int is_blank(char *line)\n+{\n+\tchar *ch;\n+\tfor (ch = line; isspace(*ch); ch++)\n+\t\t;\n+\treturn *ch == '\\0';\n+}\n+\n static int eatspace(char *line)\n {\n \tint len = strlen(line);\n@@ -243,7 +251,7 @@ #define SEEN_SUBJECT 04\n #define SEEN_BOGUS_UNIX_FROM 010\n #define SEEN_PREFIX 020\n \n-/* First lines of body can have From:, Date:, and Subject: */\n+/* First lines of body can have From:, Date:, and Subject: or be blank */\n static void handle_inbody_header(int *seen, char *line)\n {\n \tif (!memcmp(\">From\", line, 5) && isspace(line[5])) {\n@@ -279,6 +287,10 @@ static void handle_inbody_header(int *se\n \t\t\treturn;\n \t\t}\n \t}\n+\tif (isspace(line[0])) {\n+\t\tif (!(*seen & SEEN_PREFIX) && is_blank(line))\n+\t\t\treturn;\n+\t}\n \t*seen |= SEEN_PREFIX;\n }\n \n@@ -420,9 +432,7 @@ static int read_one_header_line(char *li\n \t\tif (fgets(line + ofs, sz - ofs, in) == NULL)\n \t\t\tbreak;\n \t\tlen = eatspace(line + ofs);\n-\t\tif (len == 0)\n-\t\t\tbreak;\n-\t\tif (!is_rfc2822_header(line)) {\n+\t\tif ((len == 0) || !is_rfc2822_header(line)) {\n \t\t\t/* Re-add the newline */\n \t\t\tline[ofs + len] = '\\n';\n \t\t\tline[ofs + len + 1] = '\\0';\n@@ -762,10 +772,8 @@ static void handle_body(void)\n {\n \tint seen = 0;\n \n-\tif (line[0] || fgets(line, sizeof(line), stdin) != NULL) {\n-\t\thandle_commit_msg(&seen);\n-\t\thandle_patch();\n-\t}\n+\thandle_commit_msg(&seen);\n+\thandle_patch();\n \tfclose(patchfile);\n \tif (!patch_lines) {\n \t\tfprintf(stderr, \"No patch found\\n\");\n-- \n1.4.0.g25f48-dirty\n"},{"id":"21677","messageId":"m18xo25f58.fsf_-_@ebiederm.dsl.xmission.com","threadId":"4472","inReplyTo":"Pine.LNX.4.64.0606121204220.5498@g5.osdl.org","subject":"[PATCH] Don't parse any headers in the real body of an email message.","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2006-06-12T19:48:35Z","receivedAt":"2006-06-12T19:48:35Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"\nIt was pointed out that the current behaviour might mispart a patch comment\nso remove this behaviour for now.\n\nSigned-off-by: Eric W. Biederman \n---\n mailinfo.c | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/mailinfo.c b/mailinfo.c\nindex 3696d61..325c3b2 100644\n--- a/mailinfo.c\n+++ b/mailinfo.c\n@@ -254,6 +254,8 @@ #define SEEN_PREFIX 020\n /* First lines of body can have From:, Date:, and Subject: or be blank */\n static void handle_inbody_header(int *seen, char *line)\n {\n+\tif (*seen & SEEN_PREFIX)\n+\t\treturn;\n \tif (!memcmp(\">From\", line, 5) && isspace(line[5])) {\n \t\tif (!(*seen & SEEN_BOGUS_UNIX_FROM)) {\n \t\t\t*seen |= SEEN_BOGUS_UNIX_FROM;\n-- \n1.4.0.g25f48-dirty\n"},{"id":"21679","messageId":"m17j3m5e5i.fsf@ebiederm.dsl.xmission.com","threadId":"4472","inReplyTo":"Pine.LNX.4.64.0606121204220.5498@g5.osdl.org","subject":"Re: git-applymbox broken?","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2006-06-12T20:10:01Z","receivedAt":"2006-06-12T20:10:01Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 12 Jun 2006, Eric W. Biederman wrote:\n>> \n>> Below is an example of the kind of patch that inspired me to relax the\n>> rules on parsing in body headers (this comes from Andi Kleen quilt tree).\n>\n> And this is wrong.\n>\n> We should _not_ accept crappy patches, and then start guessing at what the \n> person meant.\n>\n>>From the very beginning of git, I tried to make it extremely clear that \n> there is never any guessing going on. We don't use \"heuristics\" except as \n> a pure optimization: ie a heuristic can have a _performance_ impact, but \n> it must never EVER have semantic impact.\n>\n> SCM's are not about guessing. They are about saving the _exact_ state that \n> the user asked for. No \"let's try to be nice\", no gray areas.\n>\n> If the new git-applymbox just takes random lines from the body of the \n> email, and decides that they may be authorship information, then that is a \n> BUG. The \"From: \" line in the middle of an email may well be about \n> somebody having _discovered_ the bug, and we're quoting him as part of the \n> explanation. It does NOT mean that it's about authorship.\n>\n> So we should ONLY check for \"From:\" (and perhaps \"Subject:\" and \"Date:\") \n> at the very top of the email body. NOWHERE ELSE.\n>\n> The fact that somebody has a crappy quilt tree, and the fact that quilt is \n> very much a \"anything goes\" kind of laissez faire system does not mean, \n> and should NEVER mean that git becomes the same kind of mess of \"let's do \n> a best effort and try to guess what somebody means\" kind of thing.\n\nOk. A reasonable position. It would have been nice if you had squawked \nwhen I made that change: 2dec02b1ecafc47d4031d0a68a94c775a6a9ff9e\n\nI thought I was explicit when I did it, oh well.\n\nAs for quilt being imperfect that among other things is why I\nam slowly trying to make the tools play together better. So people\ncan use the best tool for the job, which if the integration is tight\nenough becomes a single tool.\n\n> I check and edit my emails before I apply them, and I try to teach the \n> people who send them manners and what the rules are. THAT is the way to \n> handle this, not by having the tool itself become unreliable and random\n\nWhat are the rules?\n\nThis looks like something that needs to be Documented by\nmore than just the source of git-mailinfo.\n\nThe need to skip extra blank lines was a surprise to me.\nIn looking for documentation the best I could quickly\nfind was SubmittingPatches and it only Documents the From: and ---\nlines.\n\nEric\n"},{"id":"21689","messageId":"Pine.LNX.4.63.0606130042290.25422@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4472","inReplyTo":"m13bea6w13.fsf@ebiederm.dsl.xmission.com","subject":"Re: git-applymbox broken?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-12T22:43:06Z","receivedAt":"2006-06-12T22:43:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Jun 2006, Eric W. Biederman wrote:\n\n> Index: linux/arch/i386/kernel/crash.c\n> ===================================================================\n> --- linux.orig/arch/i386/kernel/crash.c\n> +++ linux/arch/i386/kernel/crash.c\n\nTsk, tsk. Not using git, are we?\n\nCiao,\nDscho\n"},{"id":"21693","messageId":"20060612165403.a49be01c.rdunlap@xenotime.net","threadId":"4472","inReplyTo":"Pine.LNX.4.63.0606130042290.25422@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-applymbox broken?","fromName":"Randy.Dunlap","fromEmail":"rdunlap@xenotime.net","sentAt":"2006-06-12T23:54:03Z","receivedAt":"2006-06-12T23:54:03Z","isPatch":false,"sender":{"key":"rdunlap@xenotime.net","avatar":null},"body":"On Tue, 13 Jun 2006 00:43:06 +0200 (CEST) Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Mon, 12 Jun 2006, Eric W. Biederman wrote:\n> \n> > Index: linux/arch/i386/kernel/crash.c\n> > ===================================================================\n> > --- linux.orig/arch/i386/kernel/crash.c\n> > +++ linux/arch/i386/kernel/crash.c\n> \n> Tsk, tsk. Not using git, are we?\n\nwhat's your point?\nEric clearly identified where the patch came from.\n\n---\n~Randy\n"},{"id":"21701","messageId":"20060613034153.GU32457@h4x0r5.com","threadId":"4472","inReplyTo":"m1wtbn468o.fsf@ebiederm.dsl.xmission.com","subject":"Re: git-applymbox broken?","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-06-13T03:41:54Z","receivedAt":"2006-06-13T03:41:54Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Sun, Jun 11, 2006 at 05:33:59PM -0600, Eric W. Biederman wrote:\n> Linus Torvalds writes:\n> \n> > It looks like something has broken git-applymbox lately.\n> >\n> > The \"From: authorname\" lines are no longer removed from the message, and \n> > are duplicated in the commit log. This has resulted in several recent \n> > kernel commits looking like this:\n> \n> Agreed. That isn't terribly desirable.\n> Do you have the original email message some place?\n> \n> There is an odd case where if someone put the From: header\n> in the middle of the text that we now notice and process and I\n> didn't feel right about removing a line from the middle of the\n> text.\n> \n> I was fixing a nasty corner case that happens if there aren't any\n> mail headers at all passed to git-mailinfo. Where we could drop\n> lines without processing them at all.\n> \n> This doesn't look like the From: header was in the middle of the\n> message until it was imported into git so it is probably a small\n> logic error that is easily corrected. But I need to see what\n> we are parsing so I can understand what is happening.\n\nI hate to say this, because I'm bad about it, too, but we should\nprobably have a few tests for applymbox, to cover the various scenarios\ndiscussed in this thread.\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"}]}