Re: [RFC] i18n.pathencoding

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Sep 5, 2012, 11:11 UTC
Message-ID: <CACsJy8ARmPwELFhdvu_Y2kZNbYNgTzoqLzriH2oB7WtxM8D7hg@mail.gmail.com>
In-Reply-To: <7vvcftbt8o.fsf@alter.siamese.dyndns.org>

On Wed, Sep 5, 2012 at 12:19 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> On Sat, Sep 1, 2012 at 1:11 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>> @@ -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? If it's the pathname output from git that helps tab completion, then perhaps we should convert at output time rather than input, by piping all the output through a converter when we know the output is textual. That keeps all paths in the same encoding internally (I hope).

Just two cents. And I'm not against i18n.pathencoding or anything.

-- 
Duy