[Added the Git list back to delivery.]
On 2009-02-15 20:00 (+0100), Antonio García Domínguez wrote:
quoted
This bug is documented in BUGS section of "git add" manual (see "git
help add"). You can work it around with
git config --global core.quotepath false
Oh, sorry, I should have known better and RTFM. :-D
No problem at all. I was bitten by the same bug earlier, and as I wasn't
able to fix it I sent a documentation patch instead. :-)
"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.
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