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

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Sep 11, 2025, 16:48 UTC
Message-ID: <365d19ca-0a61-44f1-ab31-7e87f47d55e6@app.fastmail.com>
In-Reply-To: <20250911-pks-config-color-v1-4-3a7c79df65b1@pks.im>

On Thu, Sep 11, 2025, at 15:24, Patrick Steinhardt wrote:

> 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

Okay.  This is simple to find with a `color` search.

Show 7 quoted lines

> ANSI color escape sequence to reset the colors to normal we recommend
> the following command:
>
>     $ git config get --type=color --default="reset" ""
>
> What this command is supposed to do is to not parse any configuration
> key at all.

Or

    This command is not supposed to parse any configuration keys.

Show 9 quoted lines

> 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 with 4e51389000 (builtin/config: introduce

IMO s/with/in/ ?

> "get" subcommand, 2024-05-06), where we introduced the new "get"

nit: s/introduced the new/introduced the/

> subcommand to retrieve configuration values. The preimage of that commit
> used `git config --get-color "" "reset"` instead, which still works
> nowadays.

nit: s/still works nowadays/still works/

>
> This use case is really quite specific to parsing colors, as it wouldn't

s/use case/use-case/

> 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, but we instead parse the value into an
> ANSI escape sequence.

Two “but”?  Maybe

    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

s/use case/use-case/

Like special-case.

Show 5 quoted lines

>
> 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
> has provided a value, then we call `get_color()` directly. Do so to
> make the documented command work as expected.

In my opinion this is more difficult to read without an Oxford comma. A bullet list could break up the serial comma and the comma used to separate the “then” subclause.

    use-case:

    - if the provided config key is empty;

    - the user is asking for a color code; and

    - the user has provided a value,

    then we ...

In any case: I think a colon generally means that semicolon will be used instead of serial comma.

Show 6 quoted lines

>
> [1]: <aI+oQvQgnNtC6DVw@szeder.dev>
>
> Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
>[snip too technical diff]