Re: parse-options does not recognize "unspecified" behavior

[Jeff King <peff@peff.net>]

On Wed, Mar 16, 2016 at 04:33:03PM -0700, Stefan Beller wrote:

> The way I understand verbosity is this:
> * You can instruct a command to be more verbose if it is supported by
> adding more -v
> * --no-verbose tells the command to be not verbose, i.e. no additional output.
> 
> So my question was, if there is any command, which is verbose by
> default, and --no-verbose would make it "more quiet"? Such a case
> would be a UX bug, as a user would rather expect --quiet instead of
> --no-verbose IMO. Would such a case ever happen, that we'd want to
> give --no-verbose to decrease the amount said by the command?

Ah, I see. I agree that would be a bug, because --no-verbose is not
"more quiet". It is "cancel all previous -v". The right way to spell
that is "--quiet" (usually, see below).

> IIRC some commands use one integer variable to determine
> the amount of output, i.e. --verbose increases that variable, --quiet
> decreases it.
> What happens for example with
> 
>   git commit -v --no-verbose -v -q -q --no-quiet
> 
> In case of commit, the quietness and verbosity is done in 2 variables,
> so these are orthogonal to each other, there are even no internal checks for
> (verbosity > 0 && quietness > 0) at the same time, so it seems to be a valid
> command.

Yes, I think in general, "-v" and "-q" should work as opposites. But
that is not the case with commit, where "-v" and "-q" operate on totally
separate messages. I think that is a UX mistake, and we would not do
it that way if designing from scratch. But we're stuck with it for
historical reasons (I'd probably name "--verbose" as "--show-diff" or
something if writing it today).

Arguably cmd_commit() should be using OPT_BOOL instead of OPT__VERBOSE,
as there is no such thing as "verbose > 1" here. But I don't think there
is any real user-facing consequence of that (however, given Eric's
suggestion, I suspect it would make Pranit's problem just go away, as it
assigns rather than increments; IOW, it does the thing Eric was
suggestion OPT__VERBOSE to do).

> In case of a command where this is tracked in one variable,
> 
>   git <foo> -v --no-verbose -v -q -q --no-quiet
> 
> you'd expect:
> 
>   verbosity++ // because of first -v
>   verbosity = 0 // because of the reset with --no-verbose
>   verbosity++ // because of second -v
>   verbosity-- // because of first -q
>   verbosity-- // because of second -q
>   verbosity = 0 // because of the reset with --no-quiet
> 
> Having typed that, I think my comment was not adding value to
> the discussion, as --no-{verbose/quiet} would just reset it to 0 no matter
> if you track verbosity/quietness in one or two variables internally.

Right, in a command using OPT_VERBOSITY(), that is how it should (and
does) work. I think "commit" is just funny for historical reasons.

-Peff