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

[Patrick Steinhardt <ps@pks.im>]

On Wed, Sep 17, 2025 at 11:49:18PM -0700, Junio C Hamano wrote:
> 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
> 
> "and the user;" -> ";" perhaps?

Oh, yeah, thanks.

> >     - the user has provided a default value,
> >
> > then we call `get_color()` directly. Do so to make the documented
> > command work as expected.
> 
> If we are willing to handle this as a special case anyway, I wonder
> if it can easily be arranged to take this as a(nother) special case.
> 
>     $ git config get --type=color --default="reset"
> 
> I.e., instead of (or in addition to) "if the config key is empty",
> special case "if the config key is not given", which may be slightly
> more intuitive.
> 
> But even without it, what is presented is a vast improvement enough
> ;-)

We probably could, yeah. But it starts to become even weirder than it
already is, so I'd honestly just leave it as-is for now :) I doubt that
there's too many users out there that care about this anyway.

Patrick