Re: [PATCH] send-email: ask about and declare 8bit mails
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 12, 2010, 16:28 UTC
- Message-ID
- <7vljakfc64.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <cebe57bb68b5e8ea445e560bbe6305c915ce8a1c.1276354971.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
Show 16 quoted lines
> git-send-email passes on an 8bit mail as-is even if it does not > declare a content-type. Because the user can edit email between > format-patch and send-email, such invalid mails are unfortunately not > very hard to come by. > > Make git-send-email stop and ask about the encoding to use if it > encounters any such mail. Also provide a configuration setting to > permanently configure an encoding. > > Signed-off-by: Thomas Rast <trast@student.ethz.ch> > --- > > This takes care of what I ran into earlier today. However, there's > another problem: format-patch doesn't even mark the patch 8bit if its > patch contents (not log message) are non-ASCII. I'm really not sure > what to do there.
A project won't have uniform file encoding anyway, so even if we were to do something clever about this, it has to be per-patch. Perhaps
(0) use the attributes mechanism to allow projects to mark paths with
encoding. E.g. # everything in UTF-8 unless otherwise specified...
* encoding=UTF-8
Documentation/zh_CN/* encoding=big5 (1) for each patch, find the paths involved, and if their encodings are
the same, perhaps promote that as the encoding used for the entire
message; (2) otherwise, if there is an 8-bit encoding involved in the paths,
perhaps mark the entire message as 8-bit (binary???).I have this suspicion that (2) is very rare (you cannot transmit such a patch as a plain text message reliably afaict, so it is not done in practice), and we would probably need to make a separate patchfile for groups of paths in each encoding and attach them as MIME multiparts (ugh).
Just thinkning aloud, before morning caffeine sinks in, so please take this with a grain of salt...