Re: [PATCH v3 1/2] builtin/config.c: treat type specifiers singularly
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Apr 4, 2018, 07:57 UTC
- Message-ID
- <CAPig+cRNSYz_guBS9yNEXdAbfG+FWtvnzwsWRu0DRe0N_VkiOQ@mail.gmail.com>
- In-Reply-To
- <20180404060743.39278-2-me@ttaylorr.com>
On Wed, Apr 4, 2018 at 2:07 AM, Taylor Blau <me@ttaylorr.com> wrote:
Show 21 quoted lines
> [...] > In fact, `git config` will not accept multiple type specifiers at a > time, as indicated by: > > $ git config --int --bool some.section > error: only one type at a time. > > This patch uses `OPT_SET_INT` to prefer the _last_ mentioned type > specifier, so that the above command would instead be valid, and a > synonym of: > > $ git config --bool some.section > > This change is motivated by two urges: (1) it does not make sense to > represent a singular type specifier internally as a bitset, only to > complain when there are multiple bits in the set. `OPT_SET_INT` is more > well-suited to this task than `OPT_BIT` is. (2) a future patch will > introduce `--type=<type>`, and we would like not to complain in the > following situation: > > $ git config --int --type=int
I can understand "last wins" for related options such as "--verbose --quiet" or "--verbose=1 --verbose=2", but I have a lot of trouble buying the "last wins" argument in this context where there is no semantic relationship between, say, --bool and --expiry-date. Specifying conflicting options together is likely to be unintentional, thus reporting it as an error seems sensible, so I'm not convinced that patch's removal of that error is a good idea.
I understand that you're doing this to avoid complaining about "--int --type=int", but exactly how that case is supported should be an implementation detail; it doesn't need to bleed into the UI as an unnecessary and not-well-justified loosening of an age-old restriction. There are other ways to support "--int --type=int" without "last wins". Also, do we really need to support "--int --type=int"? Is that an expected use-case?