{"thread":{"id":"8154","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","startedAt":"2007-05-14T18:19:43Z","lastAt":"2007-05-16T11:18:57Z","messageCount":17,"participants":["Karl Hasselström","J. Bruce Fields","Matthieu Moy","Jeff King","Jeffrey C. Ollie","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":10},"messages":[{"id":"42157","messageId":"20070514181943.GA31749@diana.vm.bytemark.co.uk","threadId":"8154","inReplyTo":null,"subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-14T18:19:43Z","receivedAt":"2007-05-14T18:19:43Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-14 11:21:20 -0400, J. Bruce Fields wrote:\n\n> It includes modifications as suggested by J. Bruce Fields, Karl\n> Hasselström and Daniel Barkalow.\n\nAgh! utf8/latin1 confusion! Your mail is in latin1, but you've used\nthe utf8 byte sequence for my name.\n\nHmm. Maybe I should keep quiet, so people won't start dropping my name\ncompletely just to get rid of my complaints. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"42159","messageId":"20070514183931.GC23090@fieldses.org","threadId":"8154","inReplyTo":"20070514181943.GA31749@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-14T18:39:31Z","receivedAt":"2007-05-14T18:39:31Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, May 14, 2007 at 08:19:43PM +0200, Karl Hasselström wrote:\n> On 2007-05-14 11:21:20 -0400, J. Bruce Fields wrote:\n> \n> > It includes modifications as suggested by J. Bruce Fields, Karl\n> > Hasselström and Daniel Barkalow.\n> \n> Agh! utf8/latin1 confusion! Your mail is in latin1, but you've used\n> the utf8 byte sequence for my name.\n> \n> Hmm. Maybe I should keep quiet, so people won't start dropping my name\n> completely just to get rid of my complaints. :-)\n\nNo, I appreciate the complaint, I just don't know what to do about\nit--as far as I can tell, I've chosen utf-8 everywhere I can: my commits\nare in utf-8, and \"locale\" run from the shell reports everything as\n\"en_US.UTF-8\". But I suspect the problem is on my end somewhere--do I\nneed to do something to make sure mail I send gets a header identifying\nit as utf-8 and not iso-8859-1? I'll investigate some more tonight if I\nget the chance; any advice welcomed.\n\n--b.\n"},{"id":"42160","messageId":"vpqlkfr44ii.fsf@bauges.imag.fr","threadId":"8154","inReplyTo":"20070514183931.GC23090@fieldses.org","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-05-14T18:57:41Z","receivedAt":"2007-05-14T18:57:41Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> Content-Type: text/plain; charset=iso-8859-1\n> Content-Disposition: inline\n> Content-Transfer-Encoding: 8bit\n\n[...]\n\n> as far as I can tell, I've chosen utf-8 everywhere I can: \n\nProbably except in your mailer's configuration then!\n\n-- \nMatthieu\n"},{"id":"42161","messageId":"20070514185852.GA32331@diana.vm.bytemark.co.uk","threadId":"8154","inReplyTo":"20070514183931.GC23090@fieldses.org","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-14T18:58:52Z","receivedAt":"2007-05-14T18:58:52Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-14 14:39:31 -0400, J. Bruce Fields wrote:\n\n> No, I appreciate the complaint, I just don't know what to do about\n> it--as far as I can tell, I've chosen utf-8 everywhere I can: my\n> commits are in utf-8, and \"locale\" run from the shell reports\n> everything as \"en_US.UTF-8\". But I suspect the problem is on my end\n> somewhere--do I need to do something to make sure mail I send gets a\n> header identifying it as utf-8 and not iso-8859-1? I'll investigate\n> some more tonight if I get the chance; any advice welcomed.\n\nYour mail headers include this:\n\n Content-Transfer-Encoding: QUOTED-PRINTABLE\n Content-Type: TEXT/PLAIN; charset=ISO-8859-1\n\nbut the mail body has this:\n\n It includes modifications as suggested by J. Bruce Fields, Karl\n Hasselstr=C3=B6m and Daniel Barkalow.\n\n(That's a two-byte sequence for a single character, which indicates\nutf8 and rules out latin1.)\n\nI guess the program that generates the e-mail (git-format-patch?)\nthinks it's getting latin1 input, when it's in fact getting utf8\ninput. This is the exact same error (or rather, the exact same\nsymptom) that's happened once or twice the last week or so.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"42187","messageId":"20070515045044.GB2805@fieldses.org","threadId":"8154","inReplyTo":"20070515042200.GA10884@coredump.intra.peff.net","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-15T04:50:44Z","receivedAt":"2007-05-15T04:50:44Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, May 15, 2007 at 12:22:00AM -0400, Jeff King wrote:\n> Your original mail _does_ claim utf-8 for me. I wonder if Karl's mail is\n> getting munged by something along the path (my path is straight from vger to a\n> qmail server that I know is doing no munging). The headers I received, for\n> reference:\n\nHm. Yes, so if I send that patch to myself with git-send-email, I see\nthe same thing as you:\n\n...\n> From: \"J. Bruce Fields\" \n> To: Junio C Hamano \n> Cc: git@vger.kernel.org,\n> Johannes Schindelin \n> Subject: [PATCH 01/10] Add a birdview-on-the-source-code section to the user man\n> ual\n> Date: Mon, 14 May 2007 11:21:20 -0400\n> Message-Id: <11791560893572-git-send-email->\n> X-Mailer: git-send-email 1.5.1.4.19.g69e2\n> Content-Type: text/plain; charset=utf-8\n> Content-Transfer-Encoding: 8bit\n...\n\nBut the mail I got through the git list yesterday has some odd stuff in\nit:\n\n>From git-owner@vger.kernel.org Mon May 14 11:22:01 2007\nReceived: from vger.kernel.org ([209.132.176.167])\n\tby fieldses.org with esmtp (Exim 4.67)\n\t(envelope-from )\n\tid 1HncN6-00051C-Mh\n\tfor bfields@fieldses.org; Mon, 14 May 2007 11:22:01 -0400\nReceived: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755729AbXENPVe (ORCPT );\n\tMon, 14 May 2007 11:21:34 -0400\nX-Warning: Original message contained 8-bit characters, however during\n\t the SMTP transport session the receiving system did not announce\n\t capability of receiving 8-bit SMTP (RFC 1651-1653), and as this\n\t message does not have MIME headers (RFC 2045-2049) to enable\n\t encoding change, we had very little choice.\nX-Warning: We ASSUME it is less harmful to add the MIME headers, and\n\t convert the text to Quoted-Printable, than not to do so,\n\t and to strip the message to 7-bits.. (RFC 1428 Appendix A)\nX-Warning: We don't know what character set the user used, thus we had to\n\t write these MIME-headers with our local system default value.\nMIME-Version: 1.0\nContent-Transfer-Encoding: QUOTED-PRINTABLE\nContent-Type: TEXT/PLAIN; charset=ISO-8859-1\nReceived: (majordomo@vger.kernel.org) by vger.kernel.org id S1756250AbXENPVc\n\t(ORCPT ); Mon, 14 May 2007 11:21:32 -0400\nReceived: from mail.fieldses.org ([66.93.2.214]:54954 \"EHLO fieldses.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1755315AbXENPVb (ORCPT );\n\tMon, 14 May 2007 11:21:31 -0400\nReceived: from bfields by fieldses.org with local (Exim 4.67)\n\t(envelope-from )\n\tid 1HncMb-0004z0-E7; Mon, 14 May 2007 11:21:29 -0400\nFrom:\t\"J. Bruce Fields\" \nTo:\tJunio C Hamano \nCc:\tgit@vger.kernel.org,\n\tJohannes Schindelin \nSubject: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual\nDate:\tMon, 14 May 2007 11:21:20 -0400\nMessage-Id: <11791560893572-git-send-email->\nX-Mailer: git-send-email 1.5.1.4.19.g69e2\nSender:\tgit-owner@vger.kernel.org\nPrecedence: bulk\nX-Mailing-List:\tgit@vger.kernel.org\nStatus: RO\n\nAny idea how that happened?\n\n--b.\n"},{"id":"42188","messageId":"20070515050808.GA11745@coredump.intra.peff.net","threadId":"8154","inReplyTo":"20070515045044.GB2805@fieldses.org","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-15T05:08:08Z","receivedAt":"2007-05-15T05:08:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 15, 2007 at 12:50:44AM -0400, J. Bruce Fields wrote:\n\n> But the mail I got through the git list yesterday has some odd stuff in\n> it:\n> \n> From git-owner@vger.kernel.org Mon May 14 11:22:01 2007\n> Received: from vger.kernel.org ([209.132.176.167])\n> \tby fieldses.org with esmtp (Exim 4.67)\n> \t(envelope-from )\n> \tid 1HncN6-00051C-Mh\n> \tfor bfields@fieldses.org; Mon, 14 May 2007 11:22:01 -0400\n> Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n> \tid S1755729AbXENPVe (ORCPT );\n> \tMon, 14 May 2007 11:21:34 -0400\n> X-Warning: Original message contained 8-bit characters, however during\n> \t the SMTP transport session the receiving system did not announce\n> \t capability of receiving 8-bit SMTP (RFC 1651-1653), and as this\n> \t message does not have MIME headers (RFC 2045-2049) to enable\n> \t encoding change, we had very little choice.\n> X-Warning: We ASSUME it is less harmful to add the MIME headers, and\n> \t convert the text to Quoted-Printable, than not to do so,\n> \t and to strip the message to 7-bits.. (RFC 1428 Appendix A)\n> X-Warning: We don't know what character set the user used, thus we had to\n> \t write these MIME-headers with our local system default value.\n> MIME-Version: 1.0\n> Content-Transfer-Encoding: QUOTED-PRINTABLE\n> Content-Type: TEXT/PLAIN; charset=ISO-8859-1\n\nInteresting. vger is correct in translating, since your mail server does\n_not_ advertise the 8BITMIME extension (even though exim is 8-bit clean,\nand could handle it).\n\nHowever, the content-type is already specified, so it shouldn't need to\nrewrite. However, I notice that your original message is missing a\nMIME-Version: 1.0 header. My guess is that vger's logic is that without\nthat header, it can't trust the Content-Type you have provided (and\nindeed, not including MIME-Version violates the MIME RFCs, I believe).\n\nI assumed this was a bug in git-send-email, but looking closer, it\ndoesn't put in any mime information at all! So your sending smtp server\nis adding in the content-type header, but it's failing to add the\nMIME-Version header, which I think is a bug (I can dig up the RFC\nreference if you want).\n\nArguably, git should be generating the full MIME header-set, since it\nknows what actual encoding the message is in.\n\n-Peff\n"},{"id":"42191","messageId":"1179208673.3714.16.camel@lt21223.campus.dmacc.edu","threadId":"8154","inReplyTo":"20070515050808.GA11745@coredump.intra.peff.net","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Jeffrey C. Ollie","fromEmail":"jeff@ocjtech.us","sentAt":"2007-05-15T05:57:53Z","receivedAt":"2007-05-15T05:57:53Z","isPatch":true,"sender":{"key":"jeff@ocjtech.us","avatar":"https://gravatar.com/avatar/95918a1992f277a811c471ae7275f7e4c9d1a2e517ad290bd6aa93b97e8d34f3?d=mp&s=160"},"body":"On Tue, 2007-05-15 at 01:08 -0400, Jeff King wrote:\n> Interesting. vger is correct in translating, since your mail server\n> does\n> _not_ advertise the 8BITMIME extension (even though exim is 8-bit\n> clean,\n> and could handle it).\n\nExim can advertise the 8BITMIME extension - it's turned off by default:\n\nhttp://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo\n\nJeff\n"},{"id":"42193","messageId":"20070515062404.GA13316@coredump.intra.peff.net","threadId":"8154","inReplyTo":"1179208673.3714.16.camel@lt21223.campus.dmacc.edu","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-15T06:24:04Z","receivedAt":"2007-05-15T06:24:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 15, 2007 at 12:57:53AM -0500, Jeffrey C. Ollie wrote:\n\n> Exim can advertise the 8BITMIME extension - it's turned off by default:\n\nYes, although turning it on would just paper over the actual problem,\nwhich is that vger is rewritin the content-type header with the wrong\ncharset. It would fix the problem for Bruce, but not for other\nreceivers.\n\nThe real problem is (I believe) the lack of the MIME-Version header. I\nwill do a few test messages momentarily (which will unfortunately\nrequire me spamming the list a bit).\n\n-Peff\n"},{"id":"42199","messageId":"20070515082407.GA9096@diana.vm.bytemark.co.uk","threadId":"8154","inReplyTo":"20070515050808.GA11745@coredump.intra.peff.net","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-15T08:24:07Z","receivedAt":"2007-05-15T08:24:07Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-15 01:08:08 -0400, Jeff King wrote:\n\n> However, the content-type is already specified, so it shouldn't need\n> to rewrite. However, I notice that your original message is missing\n> a MIME-Version: 1.0 header. My guess is that vger's logic is that\n> without that header, it can't trust the Content-Type you have\n> provided (and indeed, not including MIME-Version violates the MIME\n> RFCs, I believe).\n\nYou know, this rings a bell. I've discovered that a \"MIME-Version:\n1.0\" is needed before. :-)\n\n\"stg mail\" used to have the same problem, until it was changed to use\nthe Python e-mail libraries for all that stuff. And since then I\nhaven't had problems with it.\n\n> I assumed this was a bug in git-send-email, but looking closer, it\n> doesn't put in any mime information at all! So your sending smtp\n> server is adding in the content-type header, but it's failing to add\n> the MIME-Version header, which I think is a bug (I can dig up the\n> RFC reference if you want).\n>\n> Arguably, git should be generating the full MIME header-set, since\n> it knows what actual encoding the message is in.\n\nI very much agree.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"42205","messageId":"7v3b1ylb48.fsf@assigned-by-dhcp.cox.net","threadId":"8154","inReplyTo":"20070515082407.GA9096@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-15T08:55:19Z","receivedAt":"2007-05-15T08:55:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karl Hasselström writes:\n\n> On 2007-05-15 01:08:08 -0400, Jeff King wrote:\n>\n>> However, the content-type is already specified, so it shouldn't need\n>> to rewrite. However, I notice that your original message is missing\n>> a MIME-Version: 1.0 header. My guess is that vger's logic is that\n>> without that header, it can't trust the Content-Type you have\n>> provided (and indeed, not including MIME-Version violates the MIME\n>> RFCs, I believe).\n>\n> You know, this rings a bell. I've discovered that a \"MIME-Version:\n> 1.0\" is needed before. :-)\n>\n> \"stg mail\" used to have the same problem, until it was changed to use\n> the Python e-mail libraries for all that stuff. And since then I\n> haven't had problems with it.\n>\n>> I assumed this was a bug in git-send-email, but looking closer, it\n>> doesn't put in any mime information at all! So your sending smtp\n>> server is adding in the content-type header, but it's failing to add\n>> the MIME-Version header, which I think is a bug (I can dig up the\n>> RFC reference if you want).\n>>\n>> Arguably, git should be generating the full MIME header-set, since\n>> it knows what actual encoding the message is in.\n>\n> I very much agree.\n\nIf the above statement meand git-send-email by \"git\" I would\nvery much agree.\n"},{"id":"42206","messageId":"20070515095756.GB18942@coredump.intra.peff.net","threadId":"8154","inReplyTo":"7v3b1ylb48.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-15T09:57:56Z","receivedAt":"2007-05-15T09:57:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 15, 2007 at 01:55:19AM -0700, Junio C Hamano wrote:\n\n> >> Arguably, git should be generating the full MIME header-set, since\n> >> it knows what actual encoding the message is in.\n> > I very much agree.\n> If the above statement meand git-send-email by \"git\" I would\n> very much agree.\n\nOK, the lack of a MIME-Version is clearly the problem, based on Karl's\nview of the messages I sent. I agree that git-send-email is the right\nplace to implement this (though the weird partial mime headers are\nactually an artifact of Bruce's MTA).\n\nUnfortunately, I don't think we have the encoding information any more\nat that point. We can infer how the patch was generated by looking at\nthe git-config, and that should be right 99% of the time (unless the\npatches were generated with a different config, either from another repo\nor before some settings were changed).\n\nJunio, can you confirm my understanding that:\n - if i18n.logOutputEncoding is set, then we are definitely in that\n encoding\n - otherwise, if i18n.commitEncoding is set, we should assume commits are\n in that encoding (which is just a guess, since they may have been\n generated on another config, but it's our best guess)\n - otherwise, assume utf-8\n\nIf that is OK, I will work up a patch.\n\nAlso Junio, it looks like commit 7cbcf4d5 moved parsing of the\n--encoding parameter into setup_revisions, but it's still being checked\nfor in cmd_log_init. Can you confirm that the latter is now superfluous\nand can be removed?\n\n-Peff\n"},{"id":"42223","messageId":"20070515152457.GC6794@fieldses.org","threadId":"8154","inReplyTo":"20070515050808.GA11745@coredump.intra.peff.net","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-15T15:24:58Z","receivedAt":"2007-05-15T15:24:58Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, May 15, 2007 at 01:08:08AM -0400, Jeff King wrote:\n> However, the content-type is already specified, so it shouldn't need to\n> rewrite. However, I notice that your original message is missing a\n> MIME-Version: 1.0 header. My guess is that vger's logic is that without\n> that header, it can't trust the Content-Type you have provided (and\n> indeed, not including MIME-Version violates the MIME RFCs, I believe).\n> \n> I assumed this was a bug in git-send-email, but looking closer, it\n> doesn't put in any mime information at all! So your sending smtp server\n> is adding in the content-type header,\n\nNope...\n\n> but it's failing to add the\n> MIME-Version header, which I think is a bug (I can dig up the RFC\n> reference if you want).\n> \n> Arguably, git should be generating the full MIME header-set, since it\n> knows what actual encoding the message is in.\n\n... Yes. But actually, the Content-Type header is from\ngit-format-patch:\n\n$ git format-patch --stdout 12806b^..12806b |head\nFrom 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001\nFrom: Johannes Schindelin \nDate: Thu, 10 May 2007 12:36:15 +0200\nSubject: [PATCH] Add a birdview-on-the-source-code section to the user\nmanual\nContent-Type: text/plain; charset=utf-8\nContent-Transfer-Encoding: 8bit\n\nIn http://thread.gmane.org/gmane.comp.version-control.git/42479,\na birdview on the source code was requested.\n\nSo it's a git-format-patch bug?\n\n--b.\n"},{"id":"42225","messageId":"20070515153513.GA26944@coredump.intra.peff.net","threadId":"8154","inReplyTo":"20070515152457.GC6794@fieldses.org","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-15T15:35:13Z","receivedAt":"2007-05-15T15:35:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 15, 2007 at 11:24:58AM -0400, J. Bruce Fields wrote:\n\n> ... Yes. But actually, the Content-Type header is from\n> git-format-patch:\n> \n> $ git format-patch --stdout 12806b^..12806b |head\n> From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001\n> From: Johannes Schindelin \n> Date: Thu, 10 May 2007 12:36:15 +0200\n> Subject: [PATCH] Add a birdview-on-the-source-code section to the user\n> manual\n> Content-Type: text/plain; charset=utf-8\n> Content-Transfer-Encoding: 8bit\n\nAh, interesting. I had checked that, but my test didn't produce those\nheaders. It seems we only produce them if there are non-ascii characters\nin the commit message (and I just checked with an arbitrary commit).\n\nSo really, this (totally untested) one-liner should fix it:\n\ndiff --git a/commit.c b/commit.c\nindex 922437f..5669c2f 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -1065,6 +1065,7 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,\n \t\t\tint sz;\n \t\t\tchar header[512];\n \t\t\tconst char *header_fmt =\n+\t\t\t\t\"MIME-Version: 1.0\\n\"\n \t\t\t\t\"Content-Type: text/plain; charset=%s\\n\"\n \t\t\t\t\"Content-Transfer-Encoding: 8bit\\n\";\n \t\t\tsz = snprintf(header, sizeof(header), header_fmt,\n\n\nProviding that nobody objects to sticking that extra header in\nformat-patch's output (but of course only when we actually have\nnon-ascii data). It's technically required if we want the output to be a\nvalid MIME message, but most things are unlikely to care (except vger's\napparently picky MTA).\n\n-Peff\n"},{"id":"42237","messageId":"7vlkfqj5fm.fsf@assigned-by-dhcp.cox.net","threadId":"8154","inReplyTo":"20070515095756.GB18942@coredump.intra.peff.net","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-15T18:41:01Z","receivedAt":"2007-05-15T18:41:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Unfortunately, I don't think we have the encoding information any more\n> at that point. We can infer how the patch was generated by looking at\n> the git-config, and that should be right 99% of the time (unless the\n> patches were generated with a different config, either from another repo\n> or before some settings were changed).\n>\n> Junio, can you confirm my understanding that:\n> - if i18n.logOutputEncoding is set, then we are definitely in that\n> encoding\n> - otherwise, if i18n.commitEncoding is set, we should assume commits are\n> in that encoding (which is just a guess, since they may have been\n> generated on another config, but it's our best guess)\n> - otherwise, assume utf-8\n\nI do not want to break projects whose members consistently use a\nsingle non UTF-8 encoding, and I've been hoping that in such a\nuse case they should not have to set any of these encoding\nconfiguration. So in that sense I would be somewhat reluctant\nto agree with the last one. But I am getting a feeling that it\nis a losing battle.\n\nOn the patch acceptance side, when we do _not_ have encoding\ninformation and the input does not look like a valid UTF-8, we\nassume that the input is latin-1 and convert it to UTF-8, if I\nrecall correctly. If somebody sent you a patch without encoding\nheader, and then you are forwarding that patch, not adding\nanything ourselves (because we do not know) and let the\nreceiving end to do that conversion is certainly the best; but\nif we _were_ to add anything I would suspect it would be a\nbetter idea to use the same logic to default to latin-1 or\nUTF-8. East Asian users may want to raise objections here.\n\nI think it is a reasonable compromise to do it the way you\noutlined. Doing it at patch generation time would fix the\nambiguity issues during the step 2, so it might turn out to be\nnecessary to add the encoding header to format-patch output\nafter all, but send-email needs to be able to handle messages\nthat do not have the header anyway, so probably the first step\nis to do so in send-email.\n\nWhen we update format-patch, the ambiguity at step 2 would\ndisappear. My gut feeling is that adding an extra header to\nformat-patch output would not break people's workflow nor\nscripts (I do not think it would break mine, as I either suck in\nonly the body of the message to my MUA or use send-email), but I\nam not sure.\n\n> Also Junio, it looks like commit 7cbcf4d5 moved parsing of the\n> --encoding parameter into setup_revisions, but it's still being checked\n> for in cmd_log_init. Can you confirm that the latter is now superfluous\n> and can be removed?\n\nThanks for noticing, and I think you are right. The code parses\nthe same input and sets the same global variable the same way.\n"},{"id":"42238","messageId":"7vabw6j5db.fsf@assigned-by-dhcp.cox.net","threadId":"8154","inReplyTo":"20070515153513.GA26944@coredump.intra.peff.net","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-15T18:42:24Z","receivedAt":"2007-05-15T18:42:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, May 15, 2007 at 11:24:58AM -0400, J. Bruce Fields wrote:\n>\n>> ... Yes. But actually, the Content-Type header is from\n>> git-format-patch:\n>> \n>> $ git format-patch --stdout 12806b^..12806b |head\n>> From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001\n>> From: Johannes Schindelin \n>> Date: Thu, 10 May 2007 12:36:15 +0200\n>> Subject: [PATCH] Add a birdview-on-the-source-code section to the user\n>> manual\n>> Content-Type: text/plain; charset=utf-8\n>> Content-Transfer-Encoding: 8bit\n>\n> Ah, interesting. I had checked that, but my test didn't produce those\n> headers. It seems we only produce them if there are non-ascii characters\n> in the commit message (and I just checked with an arbitrary commit).\n>\n> So really, this (totally untested) one-liner should fix it:\n>\n> diff --git a/commit.c b/commit.c\n> index 922437f..5669c2f 100644\n> --- a/commit.c\n> +++ b/commit.c\n> @@ -1065,6 +1065,7 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,\n> \t\t\tint sz;\n> \t\t\tchar header[512];\n> \t\t\tconst char *header_fmt =\n> +\t\t\t\t\"MIME-Version: 1.0\\n\"\n> \t\t\t\t\"Content-Type: text/plain; charset=%s\\n\"\n> \t\t\t\t\"Content-Transfer-Encoding: 8bit\\n\";\n> \t\t\tsz = snprintf(header, sizeof(header), header_fmt,\n>\n>\n> Providing that nobody objects to sticking that extra header in\n> format-patch's output (but of course only when we actually have\n> non-ascii data). It's technically required if we want the output to be a\n> valid MIME message, but most things are unlikely to care (except vger's\n> apparently picky MTA).\n\nThanks; I think this is a sane thing to do.\n"},{"id":"42308","messageId":"20070516111506.GC30256@coredump.intra.peff.net","threadId":"8154","inReplyTo":"7vlkfqj5fm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-16T11:15:07Z","receivedAt":"2007-05-16T11:15:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 15, 2007 at 11:41:01AM -0700, Junio C Hamano wrote:\n\n> I do not want to break projects whose members consistently use a\n> single non UTF-8 encoding, and I've been hoping that in such a\n> use case they should not have to set any of these encoding\n> configuration. So in that sense I would be somewhat reluctant\n> to agree with the last one. But I am getting a feeling that it\n> is a losing battle.\n\nI think that is a good goal, but I think we have already failed, as\ngit-format-patch generates content-type headers with charset=utf-8\n(unless the encoding variables are set up). This code was added last\nyear around this time (cdd406e38).\n\nIt looks like this is squelched in the presence of format.headers\nconfiguration. However, that still means they have to do _something_ to\nget it to work right (and I note that the fact that format.headers\nsquelches MIME headers doesn't seem to be documented anywhere...)\n\n> I think it is a reasonable compromise to do it the way you\n> outlined. Doing it at patch generation time would fix the\n> ambiguity issues during the step 2, so it might turn out to be\n> necessary to add the encoding header to format-patch output\n> after all, but send-email needs to be able to handle messages\n> that do not have the header anyway, so probably the first step\n> is to do so in send-email.\n\nAs I noted in my other email, it actually _is_ there already. So the\nMIME-Version fix just keeps the status quo, and we've been doing it this\nway for a year.\n\nIs it still worth making these guesses in send-email?\n\n> > Also Junio, it looks like commit 7cbcf4d5 moved parsing of the\n> > --encoding parameter into setup_revisions, but it's still being checked\n> > for in cmd_log_init. Can you confirm that the latter is now superfluous\n> > and can be removed?\n> Thanks for noticing, and I think you are right. The code parses\n> the same input and sets the same global variable the same way.\n\nWell, I wouldn't have noticed it if you hadn't written git-log -S. :) In\ncase you haven't fixed it yet, here it is in patch form:\n\n-- >8 --\ncmd_log_init: remove parsing of --encoding command line parameter\n\nThis was moved to the setup_revisions parsing in 7cbcf4d5, so it was\nnever being triggered.\n\nSigned-off-by: Jeff King \n---\ndiff --git a/builtin-log.c b/builtin-log.c\nindex 3744712..cebb958 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -60,13 +60,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,\n \t\trev->always_show_header = 0;\n \tfor (i = 1; i < argc; i++) {\n \t\tconst char *arg = argv[i];\n-\t\tif (!prefixcmp(arg, \"--encoding=\")) {\n-\t\t\targ += 11;\n-\t\t\tif (strcmp(arg, \"none\"))\n-\t\t\t\tgit_log_output_encoding = xstrdup(arg);\n-\t\t\telse\n-\t\t\t\tgit_log_output_encoding = \"\";\n-\t\t} else if (!strcmp(arg, \"--decorate\")) {\n+\t\tif (!strcmp(arg, \"--decorate\")) {\n \t\t\tif (!decorate)\n \t\t\t\tfor_each_ref(add_ref_decoration, NULL);\n \t\t\tdecorate = 1;\n"},{"id":"42309","messageId":"20070516111857.GD30256@coredump.intra.peff.net","threadId":"8154","inReplyTo":"7vabw6j5db.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-16T11:18:57Z","receivedAt":"2007-05-16T11:18:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 15, 2007 at 11:42:24AM -0700, Junio C Hamano wrote:\n\n> > +\t\t\t\t\"MIME-Version: 1.0\\n\"\n> Thanks; I think this is a sane thing to do.\n\nDo you want me to work up a commit message, or do you just want to\nassemble it from my other discussion?\n\nBTW, I also checked for other places where we generate a content-type.\nThe only other place I found was when we do multipart/mixed\n(log-tree.c:209), but we correctly generate the MIME-Version header\nthere.\n\n-Peff\n"}]}