From: Patrick Steinhardt Date: Mon, 15 Sep 2025 11:41:24 GMT Subject: Re: [PATCH 4/5] builtin/config: special-case retrieving colors without a key Message-ID: 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 > > 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. > > 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