# Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual 17 messages from 2007-05-14 to 2007-05-16. Participants: Karl Hasselström, J. Bruce Fields, Matthieu Moy, Jeff King, Jeffrey C. Ollie, Junio C Hamano. Thread: https://gitlist.dev/t/8154 ## Karl Hasselström, 2007-05-14 18:19 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070514181943.GA31749@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20070514181943.GA31749%40diana.vm.bytemark.co.uk ``` On 2007-05-14 11:21:20 -0400, J. Bruce Fields wrote: > It includes modifications as suggested by J. Bruce Fields, Karl > Hasselström and Daniel Barkalow. Agh! utf8/latin1 confusion! Your mail is in latin1, but you've used the utf8 byte sequence for my name. Hmm. Maybe I should keep quiet, so people won't start dropping my name completely just to get rid of my complaints. :-) -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ``` ## J. Bruce Fields, 2007-05-14 18:39 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070514183931.GC23090@fieldses.org> URL: https://gitlist.dev/e/20070514183931.GC23090%40fieldses.org In-Reply-To: <20070514181943.GA31749@diana.vm.bytemark.co.uk> ``` On Mon, May 14, 2007 at 08:19:43PM +0200, Karl Hasselström wrote: > On 2007-05-14 11:21:20 -0400, J. Bruce Fields wrote: > > > It includes modifications as suggested by J. Bruce Fields, Karl > > Hasselström and Daniel Barkalow. > > Agh! utf8/latin1 confusion! Your mail is in latin1, but you've used > the utf8 byte sequence for my name. > > Hmm. Maybe I should keep quiet, so people won't start dropping my name > completely just to get rid of my complaints. :-) No, I appreciate the complaint, I just don't know what to do about it--as far as I can tell, I've chosen utf-8 everywhere I can: my commits are in utf-8, and "locale" run from the shell reports everything as "en_US.UTF-8". But I suspect the problem is on my end somewhere--do I need to do something to make sure mail I send gets a header identifying it as utf-8 and not iso-8859-1? I'll investigate some more tonight if I get the chance; any advice welcomed. --b. ``` ## Matthieu Moy, 2007-05-14 18:57 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: URL: https://gitlist.dev/e/vpqlkfr44ii.fsf%40bauges.imag.fr In-Reply-To: <20070514183931.GC23090@fieldses.org> ``` "J. Bruce Fields" writes: > Content-Type: text/plain; charset=iso-8859-1 > Content-Disposition: inline > Content-Transfer-Encoding: 8bit [...] > as far as I can tell, I've chosen utf-8 everywhere I can: Probably except in your mailer's configuration then! -- Matthieu ``` ## Karl Hasselström, 2007-05-14 18:58 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070514185852.GA32331@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20070514185852.GA32331%40diana.vm.bytemark.co.uk In-Reply-To: <20070514183931.GC23090@fieldses.org> ``` On 2007-05-14 14:39:31 -0400, J. Bruce Fields wrote: > No, I appreciate the complaint, I just don't know what to do about > it--as far as I can tell, I've chosen utf-8 everywhere I can: my > commits are in utf-8, and "locale" run from the shell reports > everything as "en_US.UTF-8". But I suspect the problem is on my end > somewhere--do I need to do something to make sure mail I send gets a > header identifying it as utf-8 and not iso-8859-1? I'll investigate > some more tonight if I get the chance; any advice welcomed. Your mail headers include this: Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Type: TEXT/PLAIN; charset=ISO-8859-1 but the mail body has this: It includes modifications as suggested by J. Bruce Fields, Karl Hasselstr=C3=B6m and Daniel Barkalow. (That's a two-byte sequence for a single character, which indicates utf8 and rules out latin1.) I guess the program that generates the e-mail (git-format-patch?) thinks it's getting latin1 input, when it's in fact getting utf8 input. This is the exact same error (or rather, the exact same symptom) that's happened once or twice the last week or so. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ``` ## J. Bruce Fields, 2007-05-15 04:50 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070515045044.GB2805@fieldses.org> URL: https://gitlist.dev/e/20070515045044.GB2805%40fieldses.org In-Reply-To: <20070515042200.GA10884@coredump.intra.peff.net> ``` On Tue, May 15, 2007 at 12:22:00AM -0400, Jeff King wrote: > Your original mail _does_ claim utf-8 for me. I wonder if Karl's mail is > getting munged by something along the path (my path is straight from vger to a > qmail server that I know is doing no munging). The headers I received, for > reference: Hm. Yes, so if I send that patch to myself with git-send-email, I see the same thing as you: ... > From: "J. Bruce Fields" > To: Junio C Hamano > Cc: git@vger.kernel.org, > Johannes Schindelin > Subject: [PATCH 01/10] Add a birdview-on-the-source-code section to the user man > ual > Date: Mon, 14 May 2007 11:21:20 -0400 > Message-Id: <11791560893572-git-send-email-> > X-Mailer: git-send-email 1.5.1.4.19.g69e2 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit ... But the mail I got through the git list yesterday has some odd stuff in it: >From git-owner@vger.kernel.org Mon May 14 11:22:01 2007 Received: from vger.kernel.org ([209.132.176.167]) by fieldses.org with esmtp (Exim 4.67) (envelope-from ) id 1HncN6-00051C-Mh for bfields@fieldses.org; Mon, 14 May 2007 11:22:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755729AbXENPVe (ORCPT ); Mon, 14 May 2007 11:21:34 -0400 X-Warning: Original message contained 8-bit characters, however during the SMTP transport session the receiving system did not announce capability of receiving 8-bit SMTP (RFC 1651-1653), and as this message does not have MIME headers (RFC 2045-2049) to enable encoding change, we had very little choice. X-Warning: We ASSUME it is less harmful to add the MIME headers, and convert the text to Quoted-Printable, than not to do so, and to strip the message to 7-bits.. (RFC 1428 Appendix A) X-Warning: We don't know what character set the user used, thus we had to write these MIME-headers with our local system default value. MIME-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756250AbXENPVc (ORCPT ); Mon, 14 May 2007 11:21:32 -0400 Received: from mail.fieldses.org ([66.93.2.214]:54954 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755315AbXENPVb (ORCPT ); Mon, 14 May 2007 11:21:31 -0400 Received: from bfields by fieldses.org with local (Exim 4.67) (envelope-from ) id 1HncMb-0004z0-E7; Mon, 14 May 2007 11:21:29 -0400 From: "J. Bruce Fields" To: Junio C Hamano Cc: git@vger.kernel.org, Johannes Schindelin Subject: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Date: Mon, 14 May 2007 11:21:20 -0400 Message-Id: <11791560893572-git-send-email-> X-Mailer: git-send-email 1.5.1.4.19.g69e2 Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Status: RO Any idea how that happened? --b. ``` ## Jeff King, 2007-05-15 05:08 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070515050808.GA11745@coredump.intra.peff.net> URL: https://gitlist.dev/e/20070515050808.GA11745%40coredump.intra.peff.net In-Reply-To: <20070515045044.GB2805@fieldses.org> ``` On Tue, May 15, 2007 at 12:50:44AM -0400, J. Bruce Fields wrote: > But the mail I got through the git list yesterday has some odd stuff in > it: > > From git-owner@vger.kernel.org Mon May 14 11:22:01 2007 > Received: from vger.kernel.org ([209.132.176.167]) > by fieldses.org with esmtp (Exim 4.67) > (envelope-from ) > id 1HncN6-00051C-Mh > for bfields@fieldses.org; Mon, 14 May 2007 11:22:01 -0400 > Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand > id S1755729AbXENPVe (ORCPT ); > Mon, 14 May 2007 11:21:34 -0400 > X-Warning: Original message contained 8-bit characters, however during > the SMTP transport session the receiving system did not announce > capability of receiving 8-bit SMTP (RFC 1651-1653), and as this > message does not have MIME headers (RFC 2045-2049) to enable > encoding change, we had very little choice. > X-Warning: We ASSUME it is less harmful to add the MIME headers, and > convert the text to Quoted-Printable, than not to do so, > and to strip the message to 7-bits.. (RFC 1428 Appendix A) > X-Warning: We don't know what character set the user used, thus we had to > write these MIME-headers with our local system default value. > MIME-Version: 1.0 > Content-Transfer-Encoding: QUOTED-PRINTABLE > Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Interesting. vger is correct in translating, since your mail server does _not_ advertise the 8BITMIME extension (even though exim is 8-bit clean, and could handle it). However, the content-type is already specified, so it shouldn't need to rewrite. However, I notice that your original message is missing a MIME-Version: 1.0 header. My guess is that vger's logic is that without that header, it can't trust the Content-Type you have provided (and indeed, not including MIME-Version violates the MIME RFCs, I believe). I assumed this was a bug in git-send-email, but looking closer, it doesn't put in any mime information at all! So your sending smtp server is adding in the content-type header, but it's failing to add the MIME-Version header, which I think is a bug (I can dig up the RFC reference if you want). Arguably, git should be generating the full MIME header-set, since it knows what actual encoding the message is in. -Peff ``` ## Jeffrey C. Ollie, 2007-05-15 05:57 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <1179208673.3714.16.camel@lt21223.campus.dmacc.edu> URL: https://gitlist.dev/e/1179208673.3714.16.camel%40lt21223.campus.dmacc.edu In-Reply-To: <20070515050808.GA11745@coredump.intra.peff.net> ``` On Tue, 2007-05-15 at 01:08 -0400, Jeff King wrote: > Interesting. vger is correct in translating, since your mail server > does > _not_ advertise the 8BITMIME extension (even though exim is 8-bit > clean, > and could handle it). Exim can advertise the 8BITMIME extension - it's turned off by default: http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo Jeff ``` ## Jeff King, 2007-05-15 06:24 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070515062404.GA13316@coredump.intra.peff.net> URL: https://gitlist.dev/e/20070515062404.GA13316%40coredump.intra.peff.net In-Reply-To: <1179208673.3714.16.camel@lt21223.campus.dmacc.edu> ``` On Tue, May 15, 2007 at 12:57:53AM -0500, Jeffrey C. Ollie wrote: > Exim can advertise the 8BITMIME extension - it's turned off by default: Yes, although turning it on would just paper over the actual problem, which is that vger is rewritin the content-type header with the wrong charset. It would fix the problem for Bruce, but not for other receivers. The real problem is (I believe) the lack of the MIME-Version header. I will do a few test messages momentarily (which will unfortunately require me spamming the list a bit). -Peff ``` ## Karl Hasselström, 2007-05-15 08:24 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070515082407.GA9096@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20070515082407.GA9096%40diana.vm.bytemark.co.uk In-Reply-To: <20070515050808.GA11745@coredump.intra.peff.net> ``` On 2007-05-15 01:08:08 -0400, Jeff King wrote: > However, the content-type is already specified, so it shouldn't need > to rewrite. However, I notice that your original message is missing > a MIME-Version: 1.0 header. My guess is that vger's logic is that > without that header, it can't trust the Content-Type you have > provided (and indeed, not including MIME-Version violates the MIME > RFCs, I believe). You know, this rings a bell. I've discovered that a "MIME-Version: 1.0" is needed before. :-) "stg mail" used to have the same problem, until it was changed to use the Python e-mail libraries for all that stuff. And since then I haven't had problems with it. > I assumed this was a bug in git-send-email, but looking closer, it > doesn't put in any mime information at all! So your sending smtp > server is adding in the content-type header, but it's failing to add > the MIME-Version header, which I think is a bug (I can dig up the > RFC reference if you want). > > Arguably, git should be generating the full MIME header-set, since > it knows what actual encoding the message is in. I very much agree. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ``` ## Junio C Hamano, 2007-05-15 08:55 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <7v3b1ylb48.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3b1ylb48.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20070515082407.GA9096@diana.vm.bytemark.co.uk> ``` Karl Hasselström writes: > On 2007-05-15 01:08:08 -0400, Jeff King wrote: > >> However, the content-type is already specified, so it shouldn't need >> to rewrite. However, I notice that your original message is missing >> a MIME-Version: 1.0 header. My guess is that vger's logic is that >> without that header, it can't trust the Content-Type you have >> provided (and indeed, not including MIME-Version violates the MIME >> RFCs, I believe). > > You know, this rings a bell. I've discovered that a "MIME-Version: > 1.0" is needed before. :-) > > "stg mail" used to have the same problem, until it was changed to use > the Python e-mail libraries for all that stuff. And since then I > haven't had problems with it. > >> I assumed this was a bug in git-send-email, but looking closer, it >> doesn't put in any mime information at all! So your sending smtp >> server is adding in the content-type header, but it's failing to add >> the MIME-Version header, which I think is a bug (I can dig up the >> RFC reference if you want). >> >> Arguably, git should be generating the full MIME header-set, since >> it knows what actual encoding the message is in. > > I very much agree. If the above statement meand git-send-email by "git" I would very much agree. ``` ## Jeff King, 2007-05-15 09:57 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070515095756.GB18942@coredump.intra.peff.net> URL: https://gitlist.dev/e/20070515095756.GB18942%40coredump.intra.peff.net In-Reply-To: <7v3b1ylb48.fsf@assigned-by-dhcp.cox.net> ``` On Tue, May 15, 2007 at 01:55:19AM -0700, Junio C Hamano wrote: > >> Arguably, git should be generating the full MIME header-set, since > >> it knows what actual encoding the message is in. > > I very much agree. > If the above statement meand git-send-email by "git" I would > very much agree. OK, the lack of a MIME-Version is clearly the problem, based on Karl's view of the messages I sent. I agree that git-send-email is the right place to implement this (though the weird partial mime headers are actually an artifact of Bruce's MTA). Unfortunately, I don't think we have the encoding information any more at that point. We can infer how the patch was generated by looking at the git-config, and that should be right 99% of the time (unless the patches were generated with a different config, either from another repo or before some settings were changed). Junio, can you confirm my understanding that: - if i18n.logOutputEncoding is set, then we are definitely in that encoding - otherwise, if i18n.commitEncoding is set, we should assume commits are in that encoding (which is just a guess, since they may have been generated on another config, but it's our best guess) - otherwise, assume utf-8 If that is OK, I will work up a patch. Also Junio, it looks like commit 7cbcf4d5 moved parsing of the --encoding parameter into setup_revisions, but it's still being checked for in cmd_log_init. Can you confirm that the latter is now superfluous and can be removed? -Peff ``` ## J. Bruce Fields, 2007-05-15 15:24 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070515152457.GC6794@fieldses.org> URL: https://gitlist.dev/e/20070515152457.GC6794%40fieldses.org In-Reply-To: <20070515050808.GA11745@coredump.intra.peff.net> ``` On Tue, May 15, 2007 at 01:08:08AM -0400, Jeff King wrote: > However, the content-type is already specified, so it shouldn't need to > rewrite. However, I notice that your original message is missing a > MIME-Version: 1.0 header. My guess is that vger's logic is that without > that header, it can't trust the Content-Type you have provided (and > indeed, not including MIME-Version violates the MIME RFCs, I believe). > > I assumed this was a bug in git-send-email, but looking closer, it > doesn't put in any mime information at all! So your sending smtp server > is adding in the content-type header, Nope... > but it's failing to add the > MIME-Version header, which I think is a bug (I can dig up the RFC > reference if you want). > > Arguably, git should be generating the full MIME header-set, since it > knows what actual encoding the message is in. ... Yes. But actually, the Content-Type header is from git-format-patch: $ git format-patch --stdout 12806b^..12806b |head From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Thu, 10 May 2007 12:36:15 +0200 Subject: [PATCH] Add a birdview-on-the-source-code section to the user manual Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit In http://thread.gmane.org/gmane.comp.version-control.git/42479, a birdview on the source code was requested. So it's a git-format-patch bug? --b. ``` ## Jeff King, 2007-05-15 15:35 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070515153513.GA26944@coredump.intra.peff.net> URL: https://gitlist.dev/e/20070515153513.GA26944%40coredump.intra.peff.net In-Reply-To: <20070515152457.GC6794@fieldses.org> ``` On Tue, May 15, 2007 at 11:24:58AM -0400, J. Bruce Fields wrote: > ... Yes. But actually, the Content-Type header is from > git-format-patch: > > $ git format-patch --stdout 12806b^..12806b |head > From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001 > From: Johannes Schindelin > Date: Thu, 10 May 2007 12:36:15 +0200 > Subject: [PATCH] Add a birdview-on-the-source-code section to the user > manual > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit Ah, interesting. I had checked that, but my test didn't produce those headers. It seems we only produce them if there are non-ascii characters in the commit message (and I just checked with an arbitrary commit). So really, this (totally untested) one-liner should fix it: diff --git a/commit.c b/commit.c index 922437f..5669c2f 100644 --- a/commit.c +++ b/commit.c @@ -1065,6 +1065,7 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt, int sz; char header[512]; const char *header_fmt = + "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=%s\n" "Content-Transfer-Encoding: 8bit\n"; sz = snprintf(header, sizeof(header), header_fmt, Providing that nobody objects to sticking that extra header in format-patch's output (but of course only when we actually have non-ascii data). It's technically required if we want the output to be a valid MIME message, but most things are unlikely to care (except vger's apparently picky MTA). -Peff ``` ## Junio C Hamano, 2007-05-15 18:41 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <7vlkfqj5fm.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vlkfqj5fm.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20070515095756.GB18942@coredump.intra.peff.net> ``` Jeff King writes: > Unfortunately, I don't think we have the encoding information any more > at that point. We can infer how the patch was generated by looking at > the git-config, and that should be right 99% of the time (unless the > patches were generated with a different config, either from another repo > or before some settings were changed). > > Junio, can you confirm my understanding that: > - if i18n.logOutputEncoding is set, then we are definitely in that > encoding > - otherwise, if i18n.commitEncoding is set, we should assume commits are > in that encoding (which is just a guess, since they may have been > generated on another config, but it's our best guess) > - otherwise, assume utf-8 I do not want to break projects whose members consistently use a single non UTF-8 encoding, and I've been hoping that in such a use case they should not have to set any of these encoding configuration. So in that sense I would be somewhat reluctant to agree with the last one. But I am getting a feeling that it is a losing battle. On the patch acceptance side, when we do _not_ have encoding information and the input does not look like a valid UTF-8, we assume that the input is latin-1 and convert it to UTF-8, if I recall correctly. If somebody sent you a patch without encoding header, and then you are forwarding that patch, not adding anything ourselves (because we do not know) and let the receiving end to do that conversion is certainly the best; but if we _were_ to add anything I would suspect it would be a better idea to use the same logic to default to latin-1 or UTF-8. East Asian users may want to raise objections here. I think it is a reasonable compromise to do it the way you outlined. Doing it at patch generation time would fix the ambiguity issues during the step 2, so it might turn out to be necessary to add the encoding header to format-patch output after all, but send-email needs to be able to handle messages that do not have the header anyway, so probably the first step is to do so in send-email. When we update format-patch, the ambiguity at step 2 would disappear. My gut feeling is that adding an extra header to format-patch output would not break people's workflow nor scripts (I do not think it would break mine, as I either suck in only the body of the message to my MUA or use send-email), but I am not sure. > Also Junio, it looks like commit 7cbcf4d5 moved parsing of the > --encoding parameter into setup_revisions, but it's still being checked > for in cmd_log_init. Can you confirm that the latter is now superfluous > and can be removed? Thanks for noticing, and I think you are right. The code parses the same input and sets the same global variable the same way. ``` ## Junio C Hamano, 2007-05-15 18:42 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <7vabw6j5db.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vabw6j5db.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20070515153513.GA26944@coredump.intra.peff.net> ``` Jeff King writes: > On Tue, May 15, 2007 at 11:24:58AM -0400, J. Bruce Fields wrote: > >> ... Yes. But actually, the Content-Type header is from >> git-format-patch: >> >> $ git format-patch --stdout 12806b^..12806b |head >> From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001 >> From: Johannes Schindelin >> Date: Thu, 10 May 2007 12:36:15 +0200 >> Subject: [PATCH] Add a birdview-on-the-source-code section to the user >> manual >> Content-Type: text/plain; charset=utf-8 >> Content-Transfer-Encoding: 8bit > > Ah, interesting. I had checked that, but my test didn't produce those > headers. It seems we only produce them if there are non-ascii characters > in the commit message (and I just checked with an arbitrary commit). > > So really, this (totally untested) one-liner should fix it: > > diff --git a/commit.c b/commit.c > index 922437f..5669c2f 100644 > --- a/commit.c > +++ b/commit.c > @@ -1065,6 +1065,7 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt, > int sz; > char header[512]; > const char *header_fmt = > + "MIME-Version: 1.0\n" > "Content-Type: text/plain; charset=%s\n" > "Content-Transfer-Encoding: 8bit\n"; > sz = snprintf(header, sizeof(header), header_fmt, > > > Providing that nobody objects to sticking that extra header in > format-patch's output (but of course only when we actually have > non-ascii data). It's technically required if we want the output to be a > valid MIME message, but most things are unlikely to care (except vger's > apparently picky MTA). Thanks; I think this is a sane thing to do. ``` ## Jeff King, 2007-05-16 11:15 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070516111506.GC30256@coredump.intra.peff.net> URL: https://gitlist.dev/e/20070516111506.GC30256%40coredump.intra.peff.net In-Reply-To: <7vlkfqj5fm.fsf@assigned-by-dhcp.cox.net> ``` On Tue, May 15, 2007 at 11:41:01AM -0700, Junio C Hamano wrote: > I do not want to break projects whose members consistently use a > single non UTF-8 encoding, and I've been hoping that in such a > use case they should not have to set any of these encoding > configuration. So in that sense I would be somewhat reluctant > to agree with the last one. But I am getting a feeling that it > is a losing battle. I think that is a good goal, but I think we have already failed, as git-format-patch generates content-type headers with charset=utf-8 (unless the encoding variables are set up). This code was added last year around this time (cdd406e38). It looks like this is squelched in the presence of format.headers configuration. However, that still means they have to do _something_ to get it to work right (and I note that the fact that format.headers squelches MIME headers doesn't seem to be documented anywhere...) > I think it is a reasonable compromise to do it the way you > outlined. Doing it at patch generation time would fix the > ambiguity issues during the step 2, so it might turn out to be > necessary to add the encoding header to format-patch output > after all, but send-email needs to be able to handle messages > that do not have the header anyway, so probably the first step > is to do so in send-email. As I noted in my other email, it actually _is_ there already. So the MIME-Version fix just keeps the status quo, and we've been doing it this way for a year. Is it still worth making these guesses in send-email? > > Also Junio, it looks like commit 7cbcf4d5 moved parsing of the > > --encoding parameter into setup_revisions, but it's still being checked > > for in cmd_log_init. Can you confirm that the latter is now superfluous > > and can be removed? > Thanks for noticing, and I think you are right. The code parses > the same input and sets the same global variable the same way. Well, I wouldn't have noticed it if you hadn't written git-log -S. :) In case you haven't fixed it yet, here it is in patch form: -- >8 -- cmd_log_init: remove parsing of --encoding command line parameter This was moved to the setup_revisions parsing in 7cbcf4d5, so it was never being triggered. Signed-off-by: Jeff King --- diff --git a/builtin-log.c b/builtin-log.c index 3744712..cebb958 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -60,13 +60,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix, rev->always_show_header = 0; for (i = 1; i < argc; i++) { const char *arg = argv[i]; - if (!prefixcmp(arg, "--encoding=")) { - arg += 11; - if (strcmp(arg, "none")) - git_log_output_encoding = xstrdup(arg); - else - git_log_output_encoding = ""; - } else if (!strcmp(arg, "--decorate")) { + if (!strcmp(arg, "--decorate")) { if (!decorate) for_each_ref(add_ref_decoration, NULL); decorate = 1; ``` ## Jeff King, 2007-05-16 11:18 Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual Message-ID: <20070516111857.GD30256@coredump.intra.peff.net> URL: https://gitlist.dev/e/20070516111857.GD30256%40coredump.intra.peff.net In-Reply-To: <7vabw6j5db.fsf@assigned-by-dhcp.cox.net> ``` On Tue, May 15, 2007 at 11:42:24AM -0700, Junio C Hamano wrote: > > + "MIME-Version: 1.0\n" > Thanks; I think this is a sane thing to do. Do you want me to work up a commit message, or do you just want to assemble it from my other discussion? BTW, I also checked for other places where we generate a content-type. The only other place I found was when we do multipart/mixed (log-tree.c:209), but we correctly generate the MIME-Version header there. -Peff ```