File path not escaped in warning message

Hi,

I have enabled core.quotepath, but file path in warning isn't escaped: File name is 1ą.txt its content is encoded in windows-1250 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.

But I expected it to be:

warning: LF will be replaced by CRLF in 1\304\205.txt. The file will have its original line endings in your working directory.

Best regards, Janusz Białobrzewski.

Janusz Białobrzewski <jbialobr@o2.pl> writes:

Do msysgit folks want to look into this, perhaps?

Thanks.

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.

Janusz Białobrzewski <jbialobr@o2.pl> writes:

I do not know offhand if the literal <B1> is the byte value you want or not, but core.quotepath should not affect it.

The configuration is primarily about quoting paths that appear in the header part in the diff output for machine readability. In this output,

the paths are not quoted because quotepath is set to false, but in the next example, it

is quoted due to the configuration setting.

Again, <B1> in the warning message is not affected, as the quotepath configuration is not meant to affect messages that are meant for human consumption.

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. Imho, since warning comes from git, path should be quoted to make git behaviour consistent. From git-log help:

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.

Janusz Białobrzewski.

---- Wiadomość Oryginalna ----
Od: Junio C Hamano <gitster@pobox.com>
Do: Janusz Białobrzewski <jbialobr@o2.pl>
Kopia do: msysgit@googlegroups.com,  git@vger.kernel.org
Data: 5 sierpnia 2012 21:48
Temat: Re: File path not escaped in warning message

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.

<jbialobr@o2.pl> wrote on 06.08.2012 08:53:17:

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.

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.

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

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.

operation.

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

Hi Karsten,

Thanks, you helped me a lot. I see now, that logoutputencoding 
is for commit header data, not for whole log output. The name
is little missleading, so do description:
i18n.logOutputEncoding
   Encoding to use when displaying logs.

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)

also commiter and author fields.

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)

It is more like git encoding than UTF-8. 

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

It would be easier to do it if output was displayed in consistent way. I see no reason why one part of output is quoted and other is not. Another example:

$ git status warning: LF will be replaced by CRLF in 1ą.txt. The file will have its original line endings in your working directory. # On branch master # Your branch and 'origin/master' have diverged, # and have 2 and 2 different commit(s) each, respectively. # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: "1\261.txt" #

Git doesn't recode commit header when --pretty is set to format, but recodes when --pretty is set to full, raw, etc. Do you know if it is done by mistake or by design?

Thanks again, Janusz Białobrzewski.