Re: [PATCH v2 4/5] builtin/config: special-case retrieving colors without a key
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 15, 2025, 17:19 UTC
- Message-ID
- <xmqqo6rbhbv8.fsf@gitster.g>
- In-Reply-To
- <20250915-pks-config-color-v2-4-e4290bd8d13c@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
Show 37 quoted lines
> 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.