On Tue, Apr 10, 2018 at 10:44:18AM +0900, Junio C Hamano wrote: > Taylor Blau <m...@ttaylorr.com> writes: > > > `git config` has long allowed the ability for callers to provide a 'type > > specifier', which instructs `git config` to (1) ensure that incoming > > values are satisfiable under that type, and (2) that outgoing values are > > canonicalized under that type. > > Hmm, "satisfiable" is not the first word that comes to my mind to > describe "when you give me a string 'frotz', we cannot take it as an > integer". s/are satisfiable under/can be interpreted as/ perhaps?
Sure; I think that "can be interpreted as" is clearer. I have amended my patch locally, and will include this in the next re-roll, should one exist. > > In another series, we propose to extend this functionality with > > `--type=color` and `--default` to replace `--get-color`. > > > > However, we traditionally use `--color` to mean "colorize this output", > > instead of "this value should be treated as a color". > > Makes sense. > > > Currently, `git config` does not support this kind of colorization, but > > we should be careful to avoid inhabiting this option too soon, so that > > `git config` can support `--type=color` (in the traditional sense) in > > the future, if that is desired. > > Shouldn't the above `--color` instead? That is, we avoid squatting > on `--color` because we might later want to use it in the > traditional way. Also my reading stuttered around "inhabiting". It > might be just me, but perhaps s/inhabiting/squating on/? Ack, yes to both. > > In this patch, we support `--type=<int|bool|bool-or-int|...>` in > > addition to `--int`, `--bool`, and etc. This allows the aforementioned > > upcoming patch to support querying a color value with a default via > > `--type=color --default=...`, without squandering `--color`. > > Good. > > > @@ -160,30 +158,39 @@ See also <<FILES>>. > > --list:: > > List all variables set in config file, along with their values. > > > > ---bool:: > > - 'git config' will ensure that the output is "true" or "false" > > +--type <type>:: > > + 'git config' will ensure that any input or output is valid under the > > given > > + type constraint(s), and will canonicalize outgoing values in `<type>`'s > > + canonical form. > > ++ > > +Valid `<type>`'s include: > > ++ > > +- 'bool': canonicalize values as either "true" or "false". > > +- 'int': canonicalize values as simple decimal numbers. An optional suffix > > of > > + 'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, > > or > > + 1073741824 prior to output. > > It is not a new problem introduced by this patch, but these place > too much weight on the output side and may end up giving a flawed > mental model to the readers, I am afraid. > > It's not like an 'int' value internally is "2k" and shown it as 2048 > when output. In reality, we internalize it 2048 upon input and we > do not do anything special when showing, no? A 'bool' value given > with a string 'no' internally becomes 0 upon input and is shown as > 'false' upon output. > > I suspect s/prior to output/upon input/ may alleviate the issue > quite a bit. I share your concern, and I think that your suggestion would alleviate the issue entirely. I have applied these suggestions locally. :-) Thanks, Taylor
