{"thread":{"id":"10778","subject":"`git-send-email' doesn't specify `Content-Type'","startedAt":"2007-11-10T00:14:48Z","lastAt":"2007-11-11T08:56:05Z","messageCount":13,"participants":["Ludovic Courtès","Johannes Schindelin","Brian Swetland","Björn Steinbrink","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"59149","messageId":"87ode3klc7.fsf@chbouib.org","threadId":"10778","inReplyTo":null,"subject":"`git-send-email' doesn't specify `Content-Type'","fromName":"Ludovic Courtès","fromEmail":"ludo@chbouib.org","sentAt":"2007-11-10T00:14:48Z","receivedAt":"2007-11-10T00:14:48Z","isPatch":false,"sender":{"key":"ludo@chbouib.org","avatar":null},"body":"Hi,\n\nApparently, `git-send-email' doesn't specify the email's `Content-Type',\nnotably its charset, while it should really add something like:\n\n  Content-Type: text/plain; charset=UTF-8\n\nOr did I miss an option or something?\n\nThanks,\nLudovic.\n"},{"id":"59156","messageId":"Pine.LNX.4.64.0711100052290.4362@racer.site","threadId":"10778","inReplyTo":"87ode3klc7.fsf@chbouib.org","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-10T00:52:59Z","receivedAt":"2007-11-10T00:52:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 10 Nov 2007, Ludovic Court?s wrote:\n\n> Apparently, `git-send-email' doesn't specify the email's `Content-Type',\n> notably its charset, while it should really add something like:\n> \n>   Content-Type: text/plain; charset=UTF-8\n> \n> Or did I miss an option or something?\n\nApparently.  There was a thread some days ago, about that very issue.  \nPlease find and read it.\n\nCiao,\nDscho\n"},{"id":"59189","messageId":"20071110101420.GA21353@bulgaria","threadId":"10778","inReplyTo":"Pine.LNX.4.64.0711100052290.4362@racer.site","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Brian Swetland","fromEmail":"swetland@google.com","sentAt":"2007-11-10T10:14:20Z","receivedAt":"2007-11-10T10:14:20Z","isPatch":false,"sender":{"key":"swetland@google.com","avatar":"https://gravatar.com/avatar/b26b7c772097c55d8febb0fc027dd2ef577a05994a321819f49ab3c9153ac8b1?d=mp&s=160"},"body":"[Johannes Schindelin <Johannes.Schindelin@gmx.de>]\n> Hi,\n> \n> On Sat, 10 Nov 2007, Ludovic Court?s wrote:\n> \n> > Apparently, `git-send-email' doesn't specify the email's `Content-Type',\n> > notably its charset, while it should really add something like:\n> > \n> >   Content-Type: text/plain; charset=UTF-8\n> > \n> > Or did I miss an option or something?\n> \n> Apparently.  There was a thread some days ago, about that very issue.  \n> Please find and read it.\n\nThe thread I found says that git-send-email should do the right thing if\nthere are non-ascii characters, but this does not seem to be the case\nfor me.\n\nThe example I have involves a coworker's name which needs non-ascii\ncharacters.  They are properly escaped in the From: line generated by\ngit-format-patch.  git-send-email puts the generated From: line at the\ntop of the body of the email, unescapes it (to utf-8), and proceeds to\nsend the email with no Content-Type specified.\n\nThis behaviour is observed in 1.5.3.5.  A sample output from\ngit-format-patch follows, which demonstrates the problem:\n\n\n>From 3440baaed3b21138f6fc8b80e03769e3903f9c11 Mon Sep 17 00:00:00 2001\nFrom: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>\nDate: Wed, 7 Nov 2007 22:51:44 -0800\nSubject: [PATCH] hrtimer: Add timer back to pending list if it was reactivated and has already expired again.\n\nThis avoids problems with timer hardware that does not respond to timers set in the past.\n\nSigned-off-by: Brian Swetland <swetland@android.com>\n---\n kernel/hrtimer.c |   10 ++++++++--\n 1 files changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/kernel/hrtimer.c b/kernel/hrtimer.c\nindex 22a2514..7c60769 100644\n--- a/kernel/hrtimer.c\n+++ b/kernel/hrtimer.c\n@@ -1149,8 +1149,14 @@ static void run_hrtimer_softirq(struct softirq_action *h)\n \t\t\t * If the timer was rearmed on another CPU, reprogram\n \t\t\t * the event device.\n \t\t\t */\n-\t\t\tif (timer->base->first == &timer->node)\n-\t\t\t\thrtimer_reprogram(timer, timer->base);\n+\t\t\tif (timer->base->first == &timer->node) {\n+\t\t\t\tif(hrtimer_reprogram(timer, timer->base)) {\n+\t\t\t\t\t__remove_hrtimer(timer, timer->base,\n+\t\t\t\t\t\t\t HRTIMER_STATE_PENDING, 0);\n+\t\t\t\t\tlist_add_tail(&timer->cb_entry,\n+\t\t\t\t\t\t      &cpu_base->cb_pending);\n+\t\t\t\t}\n+\t\t\t}\n \t\t}\n \t}\n \tspin_unlock_irq(&cpu_base->lock);\n-- \n1.5.3.5\n"},{"id":"59203","messageId":"20071110122528.GA4977@atjola.homenet","threadId":"10778","inReplyTo":"20071110101420.GA21353@bulgaria","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-10T12:25:28Z","receivedAt":"2007-11-10T12:25:28Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.10 02:14:20 -0800, Brian Swetland wrote:\n> [Johannes Schindelin <Johannes.Schindelin@gmx.de>]\n> > Hi,\n> > \n> > On Sat, 10 Nov 2007, Ludovic Court?s wrote:\n> > \n> > > Apparently, `git-send-email' doesn't specify the email's `Content-Type',\n> > > notably its charset, while it should really add something like:\n> > > \n> > >   Content-Type: text/plain; charset=UTF-8\n> > > \n> > > Or did I miss an option or something?\n> > \n> > Apparently.  There was a thread some days ago, about that very issue.  \n> > Please find and read it.\n> \n> The thread I found says that git-send-email should do the right thing if\n> there are non-ascii characters, but this does not seem to be the case\n> for me.\n> \n> The example I have involves a coworker's name which needs non-ascii\n> characters.  They are properly escaped in the From: line generated by\n> git-format-patch.  git-send-email puts the generated From: line at the\n> top of the body of the email, unescapes it (to utf-8), and proceeds to\n> send the email with no Content-Type specified.\n\nYou mean that it converts the header field to utf-8? It doesn't do that\nhere (neither master nor 1.5.3.5) and IIRC that would be invalid anyway,\nbecause Content-Type applies to exactly that, content, not headers. Your\nsample has no non-ASCII characters (or at least I didn't see any), so\ngit-send-email doesn't add a header to specify a charset.\n\nBjörn\n\n> This behaviour is observed in 1.5.3.5.  A sample output from\n> git-format-patch follows, which demonstrates the problem:\n> \n> \n> >From 3440baaed3b21138f6fc8b80e03769e3903f9c11 Mon Sep 17 00:00:00 2001\n> From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>\n> Date: Wed, 7 Nov 2007 22:51:44 -0800\n> Subject: [PATCH] hrtimer: Add timer back to pending list if it was reactivated and has already expired again.\n> \n> This avoids problems with timer hardware that does not respond to timers set in the past.\n> \n> Signed-off-by: Brian Swetland <swetland@android.com>\n> ---\n>  kernel/hrtimer.c |   10 ++++++++--\n>  1 files changed, 8 insertions(+), 2 deletions(-)\n> \n> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c\n> index 22a2514..7c60769 100644\n> --- a/kernel/hrtimer.c\n> +++ b/kernel/hrtimer.c\n> @@ -1149,8 +1149,14 @@ static void run_hrtimer_softirq(struct softirq_action *h)\n>  \t\t\t * If the timer was rearmed on another CPU, reprogram\n>  \t\t\t * the event device.\n>  \t\t\t */\n> -\t\t\tif (timer->base->first == &timer->node)\n> -\t\t\t\thrtimer_reprogram(timer, timer->base);\n> +\t\t\tif (timer->base->first == &timer->node) {\n> +\t\t\t\tif(hrtimer_reprogram(timer, timer->base)) {\n> +\t\t\t\t\t__remove_hrtimer(timer, timer->base,\n> +\t\t\t\t\t\t\t HRTIMER_STATE_PENDING, 0);\n> +\t\t\t\t\tlist_add_tail(&timer->cb_entry,\n> +\t\t\t\t\t\t      &cpu_base->cb_pending);\n> +\t\t\t\t}\n> +\t\t\t}\n>  \t\t}\n>  \t}\n>  \tspin_unlock_irq(&cpu_base->lock);\n"},{"id":"59204","messageId":"20071110123505.GA24445@bulgaria","threadId":"10778","inReplyTo":"20071110122528.GA4977@atjola.homenet","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Brian Swetland","fromEmail":"swetland@google.com","sentAt":"2007-11-10T12:35:05Z","receivedAt":"2007-11-10T12:35:05Z","isPatch":false,"sender":{"key":"swetland@google.com","avatar":"https://gravatar.com/avatar/b26b7c772097c55d8febb0fc027dd2ef577a05994a321819f49ab3c9153ac8b1?d=mp&s=160"},"body":"[Björn Steinbrink <B.Steinbrink@gmx.de>]\n> On 2007.11.10 02:14:20 -0800, Brian Swetland wrote:\n> > \n> > The example I have involves a coworker's name which needs non-ascii\n> > characters.  They are properly escaped in the From: line generated by\n> > git-format-patch.  git-send-email puts the generated From: line at the\n> > top of the body of the email, unescapes it (to utf-8), and proceeds to\n> > send the email with no Content-Type specified.\n> \n> You mean that it converts the header field to utf-8? It doesn't do that\n> here (neither master nor 1.5.3.5) and IIRC that would be invalid anyway,\n> because Content-Type applies to exactly that, content, not headers. Your\n> sample has no non-ASCII characters (or at least I didn't see any), so\n> git-send-email doesn't add a header to specify a charset.\n\nThe first line of the patch is a From: field with Arve's name, in\nan (rfc822?) encoded format):\nFrom: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>\n\nThe mail generated by git-send-email makes this From: line the first\nline of the *body* of the generated email.  This line in the body\nis no longer escaped, the utf8 characters are visible, but the header\nof the message does not have a Content-Type indicating a non-ascii\nencoding.\n\nAttached are the result of git-format-patch and the actual email\nreceived from git-send-email (mbox format).\n\nBrian\n\n\n>From 3440baaed3b21138f6fc8b80e03769e3903f9c11 Mon Sep 17 00:00:00 2001\nFrom: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>\nDate: Wed, 7 Nov 2007 22:51:44 -0800\nSubject: [PATCH] hrtimer: Add timer back to pending list if it was reactivated and has already expired again.\n\nThis avoids problems with timer hardware that does not respond to timers set in the past.\n\nSigned-off-by: Brian Swetland <swetland@android.com>\n---\n kernel/hrtimer.c |   10 ++++++++--\n 1 files changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/kernel/hrtimer.c b/kernel/hrtimer.c\nindex 22a2514..7c60769 100644\n--- a/kernel/hrtimer.c\n+++ b/kernel/hrtimer.c\n@@ -1149,8 +1149,14 @@ static void run_hrtimer_softirq(struct softirq_action *h)\n \t\t\t * If the timer was rearmed on another CPU, reprogram\n \t\t\t * the event device.\n \t\t\t */\n-\t\t\tif (timer->base->first == &timer->node)\n-\t\t\t\thrtimer_reprogram(timer, timer->base);\n+\t\t\tif (timer->base->first == &timer->node) {\n+\t\t\t\tif(hrtimer_reprogram(timer, timer->base)) {\n+\t\t\t\t\t__remove_hrtimer(timer, timer->base,\n+\t\t\t\t\t\t\t HRTIMER_STATE_PENDING, 0);\n+\t\t\t\t\tlist_add_tail(&timer->cb_entry,\n+\t\t\t\t\t\t      &cpu_base->cb_pending);\n+\t\t\t\t}\n+\t\t\t}\n \t\t}\n \t}\n \tspin_unlock_irq(&cpu_base->lock);\n-- \n1.5.3.5\n\n\n\n>From swetland@google.com Sat Nov 10 02:04:08 2007\nReturn-Path: <swetland@google.com>\nX-Original-To: swetland@frotz.net\nDelivered-To: swetland@frotz.net\nReceived: from smtp-out.google.com (smtp-out.google.com [216.239.45.13])\n\tby mumble.frotz.net (Postfix) with ESMTP id 1BC002500D\n\tfor <swetland@frotz.net>; Sat, 10 Nov 2007 02:04:08 -0800 (PST)\nReceived: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35])\n\tby smtp-out.google.com with ESMTP id lAAA5hUj030761;\n\tSat, 10 Nov 2007 02:05:43 -0800\nDomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;\n\th=received:from:to:cc:subject:date:message-id:x-mailer;\n\tb=g2B628wRsJJahlIpNw3mgNDqOQKNMcUCPOurvqj+3fO6qLH+vpBS0ZwN1lLv6BnC7\n\tw4QLOotDo7t+nI2KgZDVQ==\nReceived: from bulgaria (bulgaria.corp.google.com [172.18.102.38])\n\tby zps35.corp.google.com with ESMTP id lAAA5e22002202;\n\tSat, 10 Nov 2007 02:05:42 -0800\nReceived: by bulgaria (Postfix, from userid 1000)\n\tid 613018F45E; Sat, 10 Nov 2007 02:05:25 -0800 (PST)\nFrom: swetland@google.com\nTo: swetland@frotz.net\nCc: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>\nSubject: [PATCH] hrtimer: Add timer back to pending list if it was reactivated and has already expired again.\nDate: Sat, 10 Nov 2007 02:05:25 -0800\nMessage-Id: <1194689125-21319-1-git-send-email-swetland@google.com>\nX-Mailer: git-send-email 1.5.3.5\nX-SpamProbe: GOOD 0.0000099 b892c7c5c469d044f28ab48846487cf5\nX-SpamCheck: OKAY\nStatus: RO\nContent-Length: 983\nLines: 33\n\nFrom: Arve Hjønnevåg <arve@android.com>\n\nThis avoids problems with timer hardware that does not respond to timers set in the past.\n\nSigned-off-by: Brian Swetland <swetland@android.com>\n---\n kernel/hrtimer.c |   10 ++++++++--\n 1 files changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/kernel/hrtimer.c b/kernel/hrtimer.c\nindex 22a2514..7c60769 100644\n--- a/kernel/hrtimer.c\n+++ b/kernel/hrtimer.c\n@@ -1149,8 +1149,14 @@ static void run_hrtimer_softirq(struct softirq_action *h)\n \t\t\t * If the timer was rearmed on another CPU, reprogram\n \t\t\t * the event device.\n \t\t\t */\n-\t\t\tif (timer->base->first == &timer->node)\n-\t\t\t\thrtimer_reprogram(timer, timer->base);\n+\t\t\tif (timer->base->first == &timer->node) {\n+\t\t\t\tif(hrtimer_reprogram(timer, timer->base)) {\n+\t\t\t\t\t__remove_hrtimer(timer, timer->base,\n+\t\t\t\t\t\t\t HRTIMER_STATE_PENDING, 0);\n+\t\t\t\t\tlist_add_tail(&timer->cb_entry,\n+\t\t\t\t\t\t      &cpu_base->cb_pending);\n+\t\t\t\t}\n+\t\t\t}\n \t\t}\n \t}\n \tspin_unlock_irq(&cpu_base->lock);\n-- \n1.5.3.5\n\n\n"},{"id":"59206","messageId":"20071110125126.GA7261@atjola.homenet","threadId":"10778","inReplyTo":"20071110123505.GA24445@bulgaria","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-10T12:51:26Z","receivedAt":"2007-11-10T12:51:26Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.10 04:35:05 -0800, Brian Swetland wrote:\n> [Björn Steinbrink <B.Steinbrink@gmx.de>]\n> > On 2007.11.10 02:14:20 -0800, Brian Swetland wrote:\n> > > \n> > > The example I have involves a coworker's name which needs non-ascii\n> > > characters.  They are properly escaped in the From: line generated by\n> > > git-format-patch.  git-send-email puts the generated From: line at the\n> > > top of the body of the email, unescapes it (to utf-8), and proceeds to\n> > > send the email with no Content-Type specified.\n> > \n> > You mean that it converts the header field to utf-8? It doesn't do that\n> > here (neither master nor 1.5.3.5) and IIRC that would be invalid anyway,\n> > because Content-Type applies to exactly that, content, not headers. Your\n> > sample has no non-ASCII characters (or at least I didn't see any), so\n> > git-send-email doesn't add a header to specify a charset.\n> \n> The first line of the patch is a From: field with Arve's name, in\n> an (rfc822?) encoded format):\n> From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>\n> \n> The mail generated by git-send-email makes this From: line the first\n> line of the *body* of the generated email.  This line in the body\n> is no longer escaped, the utf8 characters are visible, but the header\n> of the message does not have a Content-Type indicating a non-ascii\n> encoding.\n\nAh! Commit author differs from mail sender, didn't think of that. That's\nprobably the same problem as with the -s option, ie. that git-send-email\nonly looks at the existing text and not add anything it adds itself when\nchecking the encoding. Sorry for the noise.\n\nBjörn\n"},{"id":"59290","messageId":"20071111083224.GA30299@sigill.intra.peff.net","threadId":"10778","inReplyTo":"20071110125126.GA7261@atjola.homenet","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-11T08:32:24Z","receivedAt":"2007-11-11T08:32:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Nov 10, 2007 at 01:51:26PM +0100, Björn Steinbrink wrote:\n\n> On 2007.11.10 04:35:05 -0800, Brian Swetland wrote:\n> > The first line of the patch is a From: field with Arve's name, in\n> > an (rfc822?) encoded format):\n> > From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>\n\nIt's rfc2047 (and you can grep for that in git-send-email).\n\n> Ah! Commit author differs from mail sender, didn't think of that. That's\n> probably the same problem as with the -s option, ie. that git-send-email\n> only looks at the existing text and not add anything it adds itself when\n> checking the encoding. Sorry for the noise.\n\nIt's not the same problem; the '-s' problem was git-format-patch, and\nthis is git-send-email. In fact, git-format-patch correctly notes the\nencoding in the header. It is git-send-email in this case that takes the\nencoded and properly marked header, deciphers it, throws away the\noriginal encoding, and sticks it into the message body without\nconsidering the encoding of the body.\n\nSo I think you would want to:\n  1. remember the encoding pulled from the rfc2047 header\n  2. When prepending the author line to the message, consider the\n     body encoding.\n  2a. If no encoding, then the body is US-ASCII and we can presumably\n      just add\n         MIME-Version: 1.0\n         Content-Type: text/plain; charset=$enc\n  2b. If there is an encoding, we need to Iconv from the name\n      encoding to the body encoding.\n\nHowever, as it stands now, our rfc2047 unquoting _always_ assumes that\nwe are in utf-8 for the name (which is probably true if the messages\ncame out of git-format-patch with default-ish settings). So the easy,\nhackish way is probably to just add the MIME-Version and 'Content-type:\ntext/plain; charset=utf-8' headers if we unquoted the author field.\n\nIf we want to accept arbitrary messages, below is a patch to at least\nhave unquote_rfc2047 return the right information (and then on\ngit-send-email.perl:758, where we prepend $author, the encoding would\nneed to be taken into account as I described above).\n\nGiven that git-send-email is already pretty dependent on\ngit-format-patch output (and nobody has been complaining about its\nrfc2047 handling so far!) the easy, hackish way is probably the best.\n\n-Peff\n\n---\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex f9bd2e5..4f8297f 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -514,11 +514,13 @@ $time = time - scalar $#files;\n \n sub unquote_rfc2047 {\n \tlocal ($_) = @_;\n-\tif (s/=\\?utf-8\\?q\\?(.*)\\?=/$1/g) {\n+\tmy $encoding;\n+\tif (s/=\\?([^?])+\\?q\\?(.*)\\?=/$2/g) {\n+\t\t$encoding = $1;\n \t\ts/_/ /g;\n \t\ts/=([0-9A-F]{2})/chr(hex($1))/eg;\n \t}\n-\treturn \"$_\";\n+\treturn \"$_\", $encoding;\n }\n \n # use the simplest quoting being able to handle the recipient\n@@ -667,6 +669,7 @@ foreach my $t (@files) {\n \topen(F,\"<\",$t) or die \"can't open file $t\";\n \n \tmy $author = undef;\n+\tmy $author_encoding;\n \t@cc = @initial_cc;\n \t@xh = ();\n \tmy $input_format = undef;\n@@ -692,7 +695,8 @@ foreach my $t (@files) {\n \t\t\t\t\t\tnext if ($suppress_from);\n \t\t\t\t\t}\n \t\t\t\t\telsif ($1 eq 'From') {\n-\t\t\t\t\t\t$author = unquote_rfc2047($2);\n+\t\t\t\t\t\t($author, $author_encoding)\n+\t\t\t\t\t\t  = unquote_rfc2047($2);\n \t\t\t\t\t}\n \t\t\t\t\tprintf(\"(mbox) Adding cc: %s from line '%s'\\n\",\n \t\t\t\t\t\t$2, $_) unless $quiet;\n"},{"id":"59292","messageId":"20071111083525.GB30299@sigill.intra.peff.net","threadId":"10778","inReplyTo":"20071111083224.GA30299@sigill.intra.peff.net","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-11T08:35:26Z","receivedAt":"2007-11-11T08:35:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 11, 2007 at 03:32:24AM -0500, Jeff King wrote:\n\n> -\treturn \"$_\";\n> +\treturn \"$_\", $encoding;\n\nThis actually breaks other calls to unquote_rfc2047 which use a scalar\ncontext. So that would have to be fixed if this were to start a real\npatch.\n\n-Peff\n"},{"id":"59295","messageId":"20071111083915.GA18021@bulgaria","threadId":"10778","inReplyTo":"20071111083224.GA30299@sigill.intra.peff.net","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Brian Swetland","fromEmail":"swetland@google.com","sentAt":"2007-11-11T08:39:15Z","receivedAt":"2007-11-11T08:39:15Z","isPatch":false,"sender":{"key":"swetland@google.com","avatar":"https://gravatar.com/avatar/b26b7c772097c55d8febb0fc027dd2ef577a05994a321819f49ab3c9153ac8b1?d=mp&s=160"},"body":"\nThis issue with the encoding of the author got me thinking...\n\nWhat happens if the metadata has utf8 content and the patch itself has \nsome *other* non-ascii encoding (some iso-latin variant perhaps).\n\nIs there any way to deal with that situation sanely other than indicate\nthat it's 8bit content and not specify an encoding?  Is that what\nhappens currently?\n\nBrian\n"},{"id":"59297","messageId":"20071111084117.GC30299@sigill.intra.peff.net","threadId":"10778","inReplyTo":"20071111083915.GA18021@bulgaria","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-11T08:41:17Z","receivedAt":"2007-11-11T08:41:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 11, 2007 at 12:39:15AM -0800, Brian Swetland wrote:\n\n> This issue with the encoding of the author got me thinking...\n> \n> What happens if the metadata has utf8 content and the patch itself has \n> some *other* non-ascii encoding (some iso-latin variant perhaps).\n> \n> Is there any way to deal with that situation sanely other than indicate\n> that it's 8bit content and not specify an encoding?  Is that what\n> happens currently?\n\nThe body has to be in one encoding, so at the time that you know both\nencodings, you have to pick one and convert the data from the discarded\nencoding into the used encoding.\n\n-Peff\n"},{"id":"59298","messageId":"20071111084515.GB18021@bulgaria","threadId":"10778","inReplyTo":"20071111084117.GC30299@sigill.intra.peff.net","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Brian Swetland","fromEmail":"swetland@google.com","sentAt":"2007-11-11T08:45:15Z","receivedAt":"2007-11-11T08:45:15Z","isPatch":false,"sender":{"key":"swetland@google.com","avatar":"https://gravatar.com/avatar/b26b7c772097c55d8febb0fc027dd2ef577a05994a321819f49ab3c9153ac8b1?d=mp&s=160"},"body":"[Jeff King <peff@peff.net>]\n> On Sun, Nov 11, 2007 at 12:39:15AM -0800, Brian Swetland wrote:\n> \n> > This issue with the encoding of the author got me thinking...\n> > \n> > What happens if the metadata has utf8 content and the patch itself has \n> > some *other* non-ascii encoding (some iso-latin variant perhaps).\n> > \n> > Is there any way to deal with that situation sanely other than indicate\n> > that it's 8bit content and not specify an encoding?  Is that what\n> > happens currently?\n> \n> The body has to be in one encoding, so at the time that you know both\n> encodings, you have to pick one and convert the data from the discarded\n> encoding into the used encoding.\n\nThat seems potentially bad in that the transport (mailed patches) could\nbe altering the contents of the patch.  Or is this process reversed when \nthe patch is finally applied?\n\nBrian\n"},{"id":"59299","messageId":"20071111085120.GD30299@sigill.intra.peff.net","threadId":"10778","inReplyTo":"20071111084515.GB18021@bulgaria","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-11T08:51:20Z","receivedAt":"2007-11-11T08:51:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 11, 2007 at 12:45:15AM -0800, Brian Swetland wrote:\n\n> > > What happens if the metadata has utf8 content and the patch itself has \n> > > some *other* non-ascii encoding (some iso-latin variant perhaps).\n[...]\n> > The body has to be in one encoding, so at the time that you know both\n> > encodings, you have to pick one and convert the data from the discarded\n> > encoding into the used encoding.\n> \n> That seems potentially bad in that the transport (mailed patches) could\n> be altering the contents of the patch.  Or is this process reversed when \n> the patch is finally applied?\n\nMy answer was for \"how do you stick two things with different encoding\nin the same mail\" (which applies to the name + commit message\nsituation). However, we don't actually _have_ an encoding for the patch\ndata. We just assume that it matches the metadata.\n\n-Peff\n"},{"id":"59300","messageId":"20071111085605.GE30299@sigill.intra.peff.net","threadId":"10778","inReplyTo":"20071111083224.GA30299@sigill.intra.peff.net","subject":"Re: `git-send-email' doesn't specify `Content-Type'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-11T08:56:05Z","receivedAt":"2007-11-11T08:56:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 11, 2007 at 03:32:24AM -0500, Jeff King wrote:\n\n> came out of git-format-patch with default-ish settings). So the easy,\n> hackish way is probably to just add the MIME-Version and 'Content-type:\n> text/plain; charset=utf-8' headers if we unquoted the author field.\n\nHere is the quick and dirty patch. It is totally untested (as in, I\ndidn't even run git-send-email once), but maybe it can get somebody\nstarted (I left some comments about how to make it less quick and\ndirty).  My head is going to explode if I read any more of the ad-hoc\nheader parsing in git-send-email.perl.\n\n-Peff\n\n---\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex f9bd2e5..4a071f2 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -514,11 +514,13 @@ $time = time - scalar $#files;\n \n sub unquote_rfc2047 {\n \tlocal ($_) = @_;\n-\tif (s/=\\?utf-8\\?q\\?(.*)\\?=/$1/g) {\n+\tmy $encoding;\n+\tif (s/=\\?([^?])+\\?q\\?(.*)\\?=/$2/g) {\n+\t\t$encoding = $1;\n \t\ts/_/ /g;\n \t\ts/=([0-9A-F]{2})/chr(hex($1))/eg;\n \t}\n-\treturn \"$_\";\n+\treturn wantarray ? ($_, $encoding) : $_;\n }\n \n # use the simplest quoting being able to handle the recipient\n@@ -667,6 +669,9 @@ foreach my $t (@files) {\n \topen(F,\"<\",$t) or die \"can't open file $t\";\n \n \tmy $author = undef;\n+\tmy $author_encoding;\n+\tmy $has_content_type;\n+\tmy $body_encoding;\n \t@cc = @initial_cc;\n \t@xh = ();\n \tmy $input_format = undef;\n@@ -692,12 +697,20 @@ foreach my $t (@files) {\n \t\t\t\t\t\tnext if ($suppress_from);\n \t\t\t\t\t}\n \t\t\t\t\telsif ($1 eq 'From') {\n-\t\t\t\t\t\t$author = unquote_rfc2047($2);\n+\t\t\t\t\t\t($author, $author_encoding)\n+\t\t\t\t\t\t  = unquote_rfc2047($2);\n \t\t\t\t\t}\n \t\t\t\t\tprintf(\"(mbox) Adding cc: %s from line '%s'\\n\",\n \t\t\t\t\t\t$2, $_) unless $quiet;\n \t\t\t\t\tpush @cc, $2;\n \t\t\t\t}\n+\t\t\t\telsif (/^Content-type:/i) {\n+\t\t\t\t\t$has_content_type = 1;\n+\t\t\t\t\tif (/charset=\"?[^ \"]+/) {\n+\t\t\t\t\t\t$body_encoding = $1;\n+\t\t\t\t\t}\n+\t\t\t\t\tpush @xh, $_;\n+\t\t\t\t}\n \t\t\t\telsif (!/^Date:\\s/ && /^[-A-Za-z]+:\\s+\\S/) {\n \t\t\t\t\tpush @xh, $_;\n \t\t\t\t}\n@@ -756,6 +769,21 @@ foreach my $t (@files) {\n \n \tif (defined $author) {\n \t\t$message = \"From: $author\\n\\n$message\";\n+\t\tif (defined $author_encoding) {\n+\t\t\tif ($has_content_type) {\n+\t\t\t\tif ($body_encoding eq $author_encoding) {\n+\t\t\t\t\t# ok, we already have the right encoding\n+\t\t\t\t}\n+\t\t\t\telse {\n+\t\t\t\t\t# uh oh, we should re-encode\n+\t\t\t\t}\n+\t\t\t}\n+\t\t\telse {\n+\t\t\t\tpush @xh,\n+\t\t\t\t  'MIME-Version: 1.0',\n+\t\t\t\t  \"Content-Type: text/plain; charset=$author_encoding\";\n+\t\t\t}\n+\t\t}\n \t}\n \n \tsend_message();\n"}]}