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

Re: [PATCH] format-patch: teach --no-encode-headers

From
Jeff King <peff@peff.net>
Date
Apr 6, 2020, 13:30 UTC
Message-ID
<20200406133040.GB1276@coredump.intra.peff.net>
In-Reply-To
<20200406030444.GG6369@camp.crustytoothpaste.net>
On Mon, Apr 06, 2020 at 03:04:44AM +0000, brian m. carlson wrote:
Show 11 quoted lines
> On 2020-04-05 at 23:11:09, Emma Brooks wrote:
> > When commit subjects or authors have non-ASCII characters, git
> > format-patch Q-encodes them so they can be safely sent over email.
> > However, if the patch transfer method is something other than email (web
> > review tools, sneakernet), this only serves to make the patch metadata
> > harder to read without first applying it (unless you can decode RFC 2047
> > in your head). git am as well as some email software supports
> > non-Q-encoded mail as described in RFC 6531.
> 
> Do we always output UTF-8 in this case, or do we sometimes output other
> encodings if the user has specified one for the commit message?

That was my first question, too. But I think even without this option, we always respect i18n.logOutputEncoding before we even hit the email pretty-printing code. So by default it would always be utf8 (and otherwise whatever the user has asked us to output).

That would obviously be disastrous for an output encoding that isn't an ASCII superset, but that's already true for any of our output formats.

Show 7 quoted lines
> Do we know how git send-email handles such a message if it receives
> one?
> 
> I know it isn't your intention to work with git send-email in this
> patch, but it would be nice to know whether there's additional value in
> someone sending a followup patch to make git send-email use SMTPUTF8 if
> that's necessary.

I suspect this is mostly orthogonal, as that deals only with the SMTP-level addresses, which include only the actual email part (not the name) and aren't RFC2047-encoded anyway. It looks like we already leave characters in addresses untouched (I'm not even 100% sure that RFC2047 allows modifying within the local part of an addr):

  $echo foo >file
  $ git add file
  $ git -c user.email=péff@peff.net commit -m foo
  $ git format-patch -1 --stdout | grep From:
  From: Jeff King <péff@peff.net>

I did wonder if there are any standards around 8bit headers. Certainly the de facto standard for local tools (e.g., mutt reading a message you've edited in vim) is that they can be treated like a stream of ASCII-compatible bytes, and that works pretty well in practice. But if there's an IETF-endorsed method for 8bit headers, it would be nice to use it. For 8bit bodies, we're able to give a content-transfer-encoding and a content-type with the charset. But I don't know of an equivalent for headers.

-Peff
Previous: brian m. carlsonNext: brian m. carlson
Message 3 of 15 in “format-patch: teach --no-encode-headers”
  1. format-patch: teach --no-encode-headersEmma Brooks, Apr 5, 2020
  2. brian m. carlsonApr 6, 2020
  3. Jeff KingApr 6, 2020
  4. brian m. carlsonApr 6, 2020
  5. Jeff KingApr 6, 2020
  6. Junio C HamanoApr 6, 2020
  7. Emma BrooksApr 7, 2020
  8. Junio C HamanoApr 7, 2020
  9. Jeff KingApr 7, 2020
  10. Junio C HamanoApr 7, 2020
  11. Emma BrooksApr 8, 2020
  12. format-patch: teach --no-q-encode-headersEmma Brooks, Apr 7, 2020
  13. Danh DoanApr 7, 2020
  14. Emma BrooksApr 8, 2020
  15. format-patch: teach --no-encode-email-headersEmma Brooks, Apr 8, 2020

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.