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. > > 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]. However the patch send is understood correctly by email programs: see [PATCH 2/6] in this thread. I have added Content-Transfer-Encoding: 8bit to mdir.1/0001-gitweb-Prepare-for-splitting-gitweb.txt, and now it works all right. 5370:[gitweb/web@git]# git send-email [...] mdir.1/*.txt Dry-Sent [PATCHv2 0/2] gitweb: Beginnings of splitting gitweb into modules Dry-Sent [PATCHv2 1/2 (RFC?)] gitweb: Prepare for splitting gitweb Dry-Sent [PATCHv2 2/2 (PoC)] gitweb: Create Gitweb::Util module 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. Second, from email headers I have added git-send-email should _know_ that message uses UTF-8 encoding (though this is side issue, and probably result of above). -- Jakub Narebski Poland -- 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