On 04.09.12 19:19, Junio C Hamano wrote: > Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > >> On Sat, Sep 1, 2012 at 1:11 PM, Torsten Bögershausen <tboegi@xxxxxx> wrote: >>> diff --git a/parse-options.c b/parse-options.c >>> index c1c66bd..5840c18 100644 >>> --- a/parse-options.c >>> +++ b/parse-options.c >>> @@ -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. Thanks for the comments, (actually the precompose feature started as "fully" reencode, and was downsized to only do the readdir() and argv[] conversion) This leads to 2 questions: a) Do we want the reencode feature in git, so that I continue to work on it? From a performance point of view that would probably OK: The "git status" on a linux tree was slightly slower on my PC when measured with time. From the user experience there was not a difference. b) If yes, I have to admit that I don't use paths from --stdin or file so much, except "git am" or "git format-patch" Which commands are affected? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html