On Thu, 2006-05-04 at 01:15 -0700, Junio C Hamano wrote: > > * Message-ID: > <4fb292fa0604290630r19edd7ejf88642e33b350d1d@xxxxxxxxxxxxxx> > Content-type charset for send-email (Bertrand Jacquin) > > The output from format-patch by default is unmarked, which > means the commit message part is UTF-8 (by strong convention), > and the contents of the diff is whatever the contents of the > file is encoded in. Email without a Content-Type: header is supposed to be ASCII. If it contains 8-bit characters, it's invalid. It'll be interpreted by different systems in different ways -- not necessarily as UTF-8. Some may even just reject it, on grounds of RFC non-compliance. > David Woodhouse did a patch to allow specifying charset on the > command line (and default to UTF-8) which is a move in the > right direction, but Bertrand's system seems to have trouble > with it. I thought Bertrand then confirmed that he was having trouble _before_ applying my patch, too? His response when I asked it it appears without my patch was "[it] appear without in 1.3.1 and I can't seed mail with too. Also, 1.2.4 work fine here (without patch)." > I think if we were to do this we probably need to teach > format-patch to optionally do multi-part. We may not > necessarily want to mark the payload to be in the same > encoding as the commit message (not that git-apply cares -- to > it, the payload is just 8-bit unencoded text, but we would > want to protect it from getting mangled by e-mail transport). I'm not sure about that. The payload is patches, isn't it? That's just text, too -- we aren't going to deal with diffs of binary content very well _anyway_, are we? Obviously, there's nothing to stop people from storing binary blobs in GIT, but unless you want to start sending actual _blobs_ as attachments instead of sending patches, I think there's no need to play with MIME multipart stuff. I've no particular objection to it, but it's a separate issue to Bertanrd's. That's a bug-fix, while multipart is an RFE without much point, IMO. -- dwmw2 - : 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