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

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 15, 2025, 11:41 UTC
Message-ID: <aMf7ZCtK1vr9Djo7@pks.im>
In-Reply-To: <365d19ca-0a61-44f1-ab31-7e87f47d55e6@app.fastmail.com>

On Thu, Sep 11, 2025 at 06:48:45PM +0200, Kristoffer Haugsbakk wrote:

> On Thu, Sep 11, 2025, at 15:24, Patrick Steinhardt wrote:
> > This use case is really quite specific to parsing colors, as it wouldn't
> 
> s/use case/use-case/

I used to say "usecase", but eventually got corrected by one of our technical writers at GitLab that this is "use case". Wikipedia seems to agree [1].

[1]: https://en.wikipedia.org/wiki/Use_case

Show 9 quoted lines

> > 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.

That reads nicer, yup.

Show 21 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.

Yup, good suggestion.

Patrick