Subject: Re: [PATCH 0/8] builtin/config: introduce subcommands

From: Dragan Simic <[email-masked]>
Date: Thu, 07 Mar 2024 01:31:09 +0100

Hello all,

On 2024-03-07 00:46, Taylor Blau wrote:
> On Wed, Mar 06, 2024 at 09:06:08AM -0800, Junio C Hamano wrote:
>> Patrick Steinhardt <[email-masked]> writes:
>> 
>> >   - `git config foo.bar` -> `git config get foo.bar`
>> >
>> >   - `git config foo.bar value` -> `git config set foo.bar value`
>> 
>> I actually have been perfectly OK with the above two, but I agree
>> that ...
> 
> Same here, though I think that we are probably both biased by many 
> years
> of familiarity with the existing syntax.

Ditto.  Though, having "get" and "set" commands will be nice, making it
all more self descriptive.

>> >   - `git config foo.bar value value-pattern` -> `git config set-all
>> >     foo.bar value value-pattern`
>> 
>> ... this was less than discoverable, and would be a good update.
>> This one ...
> 
> Agreed.

Also agreed.  Having the point below in mind, perhaps we could actually
end up with "set --all" instead of "set-all".

>> >   - `git config --get-urlmatch` -> `git config get-urlmatch`.
>> 
>> ... is a Meh to me, personally.  I'd not actively push it
>> enthusiastically, but I'd passively accept its existence.
> 
> I don't have strong feelings about this, but I wonder if `--urlmatch`
> (or `--url-match`) might be an argument to the "get" mode of this
> sub-command instead. Something like `git config get --urlmatch` feels
> much more natural to me than `git config get-urlmatch`.

Good point.  I'd vote for having "get --urlmatch" or "get --url-match",
because it feels more natural to me, it doesn't "clog up" the command
space, and such an approach, in general, allows git-config(1) to be
expanded later easier with more new arguments for the existing commands.