Re: [RFC] i18n.pathencoding

Torsten Bögershausen [off-list ref] writes:

On 05.09.12 13:11, Nguyen Thai Ngoc Duy wrote:

quoted

On Wed, Sep 5, 2012 at 12:19 AM, Junio C Hamano [off-list ref] wrote:

quoted

Nguyen Thai Ngoc Duy [off-list ref] writes:

quoted

On Sat, Sep 1, 2012 at 1:11 PM, Torsten Bögershausen [off-list ref] wrote:

quoted

@@ -476,7 +476,7 @@ int parse_options(int argc, const char **argv, const char *prefix,
                usage_with_options(usagestr, options);
        }

-       precompose_argv(argc, argv);
+       reencode_argv(argc, argv);
        return parse_options_end(&ctx);
 }

If you have to re-encode command line arguments, what about paths
coming --stdin or a file?

That problem is inherited from the MacOS precompose topic this one
builds on.  Not that it is unimportant to fix, though.

On fixing that. 76759c7 describes the change as:

    The argv[] conversion allows to use the TAB filename completion done
    by the shell on command line.  It tolerates other tools which use
    readdir() to feed decomposed file names into git.

How come git's internal conversion helps TAB filename completion,
which is done before git is executed?

Because the shell use readdir() itself when <TAB> is pressed

$echo Bö > Bö
$echo Ba > Ba
$ls 
Bo ̈
Ba

# The terminal program of Mac OS shows the decomposed "ö" correctly,
"Bö" is shown as "Bö", while xterm shows "Bö" as "Bo ̈",
that is "o" followod by a "combining diaresis".

The shell seems to do the same:
to add Bö to git,

$git add Bo<TAB>

needs to be used.
And as a result, the sheel will pass the "o" in decomposed unicode to git,
which is corrected in precompose_argv().

Well explained; this does not have anything to do with what Git
outputs.