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