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

From: Jeff King <peff@peff.net>
Date: Mar 17, 2016, 01:43 UTC
Message-ID: <20160317014310.GA12830@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kYVT0cq8XgruZ+i_gGuSDySE+s3POU95PXyra9DwVGLkQ@mail.gmail.com>

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

Show 10 quoted lines

> 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).

Show 11 quoted lines

> 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).

Show 16 quoted lines

> 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