Hi Janusz,

It seems you're mixing up a few completely unrelated concepts here.

Core.quotepath enables quoting and escaping of special characters in file 
names. This has nothing to do with character set encoding of file names 
(i.e. Cp1250/ISO-8859-2/UTF-8). AFAIK, apart from git-svn, git currently 
doesn't support character set re-coding of file names at all, so 
core.quotepath and encoding are completely unrelated.

Regarding git-log / git-diff output, there are basically three different 
character set encodings involved:
1. commit log messages: re-coded to i18n.logoutputencoding (usually UTF-8)
2. file content: printed verbatim (no re-coding); gui tools such as gitk 
may decode this based on gui.encoding or .gitattributes settings
3. everything else (file names, diff headers, error / warning messages): 
always UTF-8 (at least in Git for Windows)

Gui tools such as gitk decode this output line by line using the 
appropriate encoding.

<jbial...@o2.pl> wrote on 06.08.2012 08:53:17:
> File name is 1ą.txt its content is encoded in windows-1250

File name encoding and file content encoding are completely unrelated. 
File name encoding in current Git for Windows is *always* UTF-8, file 
content encoding can be anything.

> Output of git diff after reencoding to windows1250 is:
> warning: LF will be replaced by CRLF in 1Ä….txt.
> The file will have its original line endings in your working directory.

This looks like the file name is UTF-8, but reinterpreted (not reencoded) 
as if it were Cp1250. However, as stated above, you cannot simply 
interpret the entire git-log / git-diff output as beeing one particular 
encoding, as the encoding may vary on a line by line basis.

> Here is output from linux:
> [janusz@mikrus JavaCommon]$ git config --add core.quotepath false
> [janusz@mikrus JavaCommon]$ git diff  --unified=3 -- "1ą.txt"
> warning: LF will be replaced by CRLF in 1<B1>.txt.
> The file will have its original line endings in your working directory.

"<B1>" looks like less's escaping with missing LESSCHARSET setting.

Additionally, your Linux box seems to be set up with ISO-8859-2 system 
encoding. Git repositories created on this system will not be portable, 
i.e. using the same repository on other Linux systems, Git for Windows, 
Cygwin-git, or JGit/EGit will result in completely broken file names. The 
quasi-standard file name encoding in git repositories is UTF-8.

> There is nothing said in the manual, that core.quotepath affects 
> only header. But it is not the point. You don't know which part of 
> git output will be consumed by machine. Warning message is addressed
> to human, but it can be consumed by program in the same way as all 
> other messages and output data.

Error / warning messages may be localized, so they are particularly 
unsuitable for consumption by other programs. That's why many git commands 
have special switches to make their output machine readable (e.g. -z). 
Incidentally, 'git-log -z' also disables core.quotepath. So if you write a 
program that parses git output, and you're using the proper 'machine 
readable' version, you should never have to worry about quoted paths, 
irrespective of the core.quotepath setting.

> Imho, since warning comes from git, path should be quoted to
> make git behaviour consistent. 
> From git-log help:
> > Note that we deliberately chose not to re-code the commit log 
> message when a commit is made to force UTF-8 at the commit object 
> level, because re-coding to UTF-8 is not necessarily a reversible 
> If re-coding from one encoding to other is not necessarily a 
> reversible operation, and you can set logoutputencoding to any 
> encoding you wish, you may loose some charatcers while recoding file
> path in warning message. Quoting it would be desired then.

The i18n.commitencoding and i18n.logoutputencoding settings only affect 
commit log messages. They are completely unrelated to error / warning 
messages, file names, or file name quoting.

Hope that helps,


Reply via email to