On Tue, 3 May 2011, Jakub Narebski wrote: > On Sat, 30 Apr 2011, Ãyvind A. Holm wrote: > > On 29 April 2011 23:31, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > A tangent. It is curious why [PATCH 2/6] alone ended up with an encoded > > > "Subject" header, like this: > > > > > > ÂSubject: =?UTF-8?q?=5BPATCH=202/6=5D=20gitweb=3A=20Change=20the=20 > > > Â way=20=22content=20tags=22=20=28=27ctags=27=29=20are=20handled?= > > > > > > The message actually has the above as a long single line, as can be seen at > > > http://article.gmane.org/gmane.comp.version-control.git/172479/raw > > > > > > Just being curious. > > > > This seems as the same thing that I reported on 2010-04-25 23:35:49Z, > > <http://thread.gmane.org/gmane.comp.version-control.git/145774>. If there's a > > character above U+007F in the log message below line #2, the Subject: line is > > garbled. In this case it is, it's the "Ã" in Uwe's name that leads to this > > error. Note: this line was added "by hand" when editing patch, so commit message that git-format-patch seen did not contain any non-ASCII characters. Otherwise fir-format-patch would add correct MIME headers itself. > > A test to reproduce this is at <https://gist.github.com/378785>, but it seems > > as this was fixed between v1.7.4.1-292-ge2a57aa and v1.7.4.1-343-ga91df69 , > > probably happened in dc7f96f (Merge branch 'jk/format-patch-multiline-header'). > > The patch at <http://article.gmane.org/gmane.comp.version-control.git/172479/raw> > > was generated with git-1.7.3, so it would trigger the error in this case. > > I have just upgraded git to 1.7.5, and unfortunately it still has the > same bug (note that UTF-8 character was introduced while editing patch, > so git-format-patch doesn't see it): > > 5369:[gitweb/web@git]# git send-email [...] --dry-run mdir.1/*.txt > The following files are 8bit, but do not declare a Content-Transfer-Encoding. > mdir.1/0001-gitweb-Prepare-for-splitting-gitweb.txt > Which 8bit encoding should I declare [UTF-8]? <ENTER> > Dry-Sent [PATCHv2 0/2] gitweb: Beginnings of splitting gitweb into modules > Dry-Sent =?UTF-8?q?=5BPATCHv2=201/2=20=28RFC=3F=29=5D=20gitweb=3A=20Prepare=20for=20splitting=20gitweb?= > Dry-Sent [PATCHv2 2/2 (PoC)] gitweb: Create Gitweb::Util module > > Note that having > > MIME-Version: 1.0 > Content-Type: text/plain; charset=utf-8 > > is not enough[1]. Perhaps something like attached patch could be beginning of fixing this issue. > Footnotes: > ^^^^^^^^^^ > [1]: Note that git-send-email does something strange: first, the problem > is with Content-Transfer-Encoding, and git-send-email asks for 8bit > encoding, suggesting UTF-8, instead of asking for transfer encoding, > sugesting e.g. 8bit. Actually git-send-email assumes 8bit if not stated, but it does not parse 'Content-Type' header for encoding to be used, perhaps correctly assuming that if required 'Content-Transfer-Encoding' is missing, then 'Content-Type' is most probably missing as well. -- >8 ---------- >8 -- Subject: [PATCH] git-send-email: Do not encode Subject if not required If "Subject:" header of an email does not contain non-ASCII characters, then we don't need to RFC-2047 encode it, even if file had broken encoding. Signed-off-by: Jakub Narebski <jnareb@xxxxxxxxx> --- git-send-email.perl | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index 98ab33a..1c6b1a8 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1281,7 +1281,9 @@ foreach my $t (@files) { $body_encoding = $auto_8bit_encoding; } - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) { + if ($broken_encoding{$t} && + !is_rfc2047_quoted($subject) && + $subject =~ /[^[:ascii:]]/) { $subject = quote_rfc2047($subject, $auto_8bit_encoding); } -- 1.7.5 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html