Re: [PATCH v2 4/5] builtin/config: special-case retrieving colors without a key

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

Patrick Steinhardt <ps@pks.im> writes:

> Our documentation for git-config(1) has a section where it explains how
> to parse and use colors as Git would configure them. In order to get the
> ANSI color escape sequence to reset the colors to normal we recommend
> the following command:
>
>     $ git config get --type=color --default="reset" ""
>
> This command is not supposed to parse any configuration keys. Instead,
> it is expected to parse the "reset" default value and turn it into a
> proper ANSI color escape sequence.
>
> It was reported though [1] that this command doesn't work:
>
>     $ git config get --type=color --default="reset" ""
>     error: key does not contain a section:
>
> This error was introduced in 4e51389000 (builtin/config: introduce "get"
> subcommand, 2024-05-06), where we introduced the "get" subcommand to
> retrieve configuration values. The preimage of that commit used `git
> config --get-color "" "reset"` instead, which still works.
>
> This use case is really quite specific to parsing colors, as it wouldn't
> make sense to give git-config(1) a default value and an empty config key
> only to return that default value unmodified. But with `--type=color` we
> don't return the value directly; we instead parse the value into an ANSI
> escape sequence.
>
> As such, we can easily special-case this one use case:
>
>     - If the provided config key is empty;
>
>     - the user is asking for a color code and the user; and
>
>     - the user has provided a default value,
>
> then we call `get_color()` directly. Do so to make the documented
> command work as expected.

Yup, the UI is still ugly because this is not config at all X-<.
Only because we lack "I have a color name.  Please parse it into
ANSI sequence" command, we are abusing the "git config" command and
using "--default" as "here is that color name I am asking about"
argument.  Even if we were to add a more intuitive "parse --color"
command, the (ab)use of "git config" for this purpose has been with
us for the many years and cannot be dropped--and under that constraints,
I agree that this patch is the best we could do.

Thanks for working on this.