Jeff King kirjoitti: > We always use 'utf-8' as the encoding, since we currently > have no way of getting the information from the user. > > This also refactors the quoting of recipient names, since > both processes can share the rfc2047 quoting code. These patches seem to work except that the quoting of Subject field works only if user types a non-Ascii text to the "What subject should the initial email start with?" prompt. If she changes the subject in editor it won't be rfc2047-quoted. Thank you anyway, I think we're going to right direction. I think 'git send-mail --compose' is nice way to produce introductory message to patch series. If --compose doesn't support MIME encoding reasonable way, user may have to write and send intro message with real MUA and find out the Message-Id for correct In-Reply-To field for the actual patch series. E-mail agents KMail and Mutt have setting for preferred encodings for outgoing mail. It's a list of encodings, like "us-ascii,iso-8859-1,utf-8". The first one that fits (including From, To, Cc, Subject, the body, ...?) is used, so there is some kind of detection of content after the message has been composed. If portable content encoding detection is difficult or considered unnecessary, then I think a documented configurable option is fine (UTF-8 by default). -- 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
