[PATCH/RFC] git-send-email: Do not encode Subject if not required (was: git-send-email and non 7bit clean message)

[Jakub Narebski <jnareb@gmail.com>]

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@pobox.com> 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@gmail.com>
---
 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