From: Dragan Simic Date: Thu, 07 Mar 2024 00:31:09 GMT Subject: Re: [PATCH 0/8] builtin/config: introduce subcommands Message-ID: In-Reply-To: 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 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.