Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
> 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@xxxxxxxxxxxxxxx>
> ---
>
> 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...
--
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