git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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...

Previous: Thomas RastNext: Thomas Rast
Message 9 of 22 in “bash completion: Support "divergence from upstream" warnings in __git_ps1”
  1. 0/2 bash completion: Support "divergence from upstream" warnings in __git_ps1Thomas Rast, Jun 12, 2010
  2. 1/2 rev-list: introduce --count optionThomas Rast, Jun 12, 2010
  3. 2/2 bash completion: Support "divergence from upstream" warnings in __git_ps1Thomas Rast, Jun 12, 2010
  4. Junio C HamanoJun 14, 2010
  5. Thomas RastJun 14, 2010
  6. SZEDER GáborJun 14, 2010
  7. vger doesn't like UTF-8 from send-emailThomas Rast, Jun 12, 2010
  8. send-email: ask about and declare 8bit mailsThomas Rast, Jun 12, 2010
  9. Junio C HamanoJun 12, 2010
  10. Thomas RastJun 13, 2010
  11. Michael WittenJun 13, 2010
  12. Erik Faye-LundJun 14, 2010
  13. bash completion: Support "divergence from upstream" messages in __git_ps1Andrew Sayers, Jun 12, 2010
  14. Thomas RastJun 14, 2010
  15. [PATCHv4] bash completion: Support "divergence from upstream" messages in __git_ps1Andrew Sayers, Jun 15, 2010
  16. Junio C HamanoJun 16, 2010
  17. Thomas RastJun 16, 2010
  18. 0/2 bash completion: Support "divergence from upstream" messages in __git_ps1Andrew Sayers, Jun 17, 2010
  19. Junio C HamanoJun 18, 2010
  20. Andrew SayersJun 18, 2010
  21. 1/2 bash completion: Support "divergence from upstream" messages in __git_ps1Andrew Sayers, Jun 17, 2010
  22. 2/2 bash-completion: Fix __git_ps1 to work with "set -u"Andrew Sayers, Jun 17, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.