Re: [PATCH v3 1/4] quote: add c quote flag to ignore core.quotePath

[Junio C Hamano <gitster@pobox.com>]

Justin Tobler <jltobler@gmail.com> writes:

> The output of `cq_must_quote()` is affected by `core.quotePath`. This is
> undesirable for operations that want to ensure consistent output
> independent of config settings.
>
> Introduce the `CQUOTE_IGNORE_CONFIG` flag for the `quote_c_style*`
> functions which when set makes `cq_must_quote()` always follow the
> default behavior (core.quotePath=true) regardless of how its set in the
> config.

Hmph.  

I was hoping that we can flip the default for 'core.quotePath' to
'no' at Git 3.0 boundary, to help folks in non-ASCII locale.  If
this is about emitting pipe-able output out of rev-list, unlike a
patch that is to be e-mailed (and being 8-bit clean was a risky
assumption to make in 2005) that core.quotePath was originally
invented for, it is more so that we would not want to force the
receiving end to unquote, no?

So regardless of what the future default value of core.quotePath
would be, I am not convinced that it is a good idea to octal quote
any and all bytes outside the ASCII range in the rev-list output.

After all, "git rev-list --objects" would show such a path without
quoting, no [*]?

    Side note: the path in the output from "git rev-list --objects"
    is a hack to allow receiving end to compute a path hash, and
    does not have to be strictly reversible, so it emits verbatim
    bytes but truncates the output at LF to preserve the one-line
    one-object output format.

We do need to quote certain bytes (e.g., LF cannot be allowed
verbatim, when the output is line-oriented, and we use C-quote,
which means literal double-quote needs to be also quoted), so we
cannot mimic paths emitted by "git rev-list --objects", but I do not
think it buys us much to quote non-ASCII bytes these days.