[MERGE] Support 3 noise levels in commit

[Ian Clatworthy]

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> I don't think this is the right way to achieve it.
> 
>> a) --quiet already has a meaning in the codebase.  I don't think it
>> makes sense to reuse it.  Also, does it work with aliases?
> 
> --quiet (in the global sense) doesn't. Because of when aliases are
> parsed versus when global arguments are parsed, you can't add a global
> arg to aliases.
> 
> That said, I think '--quiet' should have an effect on commit. I don't
> think he is mis-using it to have that sort of effect.

I don't feel I'm mis-using -q/--quiet at all. I'd argue I'm fixing a bug
because, right now, -q doesn't do what users expect on commit.

>> b) "bzr commit --quiet --verbose" should select "verbose", the way the
>> rest of our options behave.

I agree conceptually. Practically, it's a non-issue because that would
only happen if --quiet was part of an alias (not possible right now?)
and a user wanted to override their regular noise level (of silence).
The 99% case is having verbose as part of the alias and overriding that
on the command line with -q.

>> Instead, I think it makes more sense to treat verbose as an enumeration,
>> with --silent, --normal and --verbose as individual flags.
>> "verbose=False" can be handled as a legacy value.

How will --silent differ from --quiet?

I'm good with a 3 level enumeration assuming it's forwardly compatible
with the implicit one in our UI already (-q, nothing, -v) and that we
agree to adopt it across every command, not just commit.

> Again, global options muddy the waters here. We need to change how we
> parse those before we can have that sort of effect.

I'm happy to fix that if required.

This started out as a simple DWIM patch for -q/-v on commit. Does it
need to become a "fix and test noise level selection and handling across
the product" to get merged?

Ian C.