Re: "add -p" + filenames with UTF-8 multibyte characters = "No changes"

From: Jeff King <peff@peff.net>
Date: Feb 16, 2009, 03:36 UTC
Message-ID: <20090216033634.GA12461@coredump.intra.peff.net>
In-Reply-To: <87prhjqzwb.fsf@iki.fi>

On Sun, Feb 15, 2009 at 09:11:00PM +0200, Teemu Likonen wrote:

> "core.quotepath=false" is good for other purposes too. It prints UTF-8
> filenames in diff headers in form that is actually readable. I think it
> would be better default.

I am not opposed to setting this as a default, but I think there may be some encoding issues to be dealt with. At the very least, format-patch generates messages without a content-type header. E.g.,:

  $ touch föö && git add . && git commit -m one
  $ echo content >föö && git commit -a -m two

  $ git format-patch --stdout HEAD^ | sed '/^$/q'

vs

  $ git config core.quotepath false
  $ git format-patch --stdout HEAD^ | sed '/^$/q'

So now we have non-ascii in our email, but no header specifying encoding. Previous experience has shown that intermediate MTAs (like vger) will add their own header with whatever encoding they think is sensible (in the case of vger, iso8859-1), corrupting the mail if they guess wrong.

But what is the right encoding to specify? We can guess that it is whatever the commit message is in (defaulting to utf-8). It is by no means correct, but it would probably work pretty well in practice.

On the other hand, we already have the same problem for encoded file _contents_. So maybe it is not a big problem in practice.

-Peff