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

>> 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).
>
> Yeah, as a long-time 'git commit -v' user I never really thought about
> the name of the option, but when I pointed out the multiple verbose
> levels it struck me as a rather unfortunate name for this feature,
> too.  Oh, well, we are stuck with it indeed.
>
> However, that doesn't mean that we have to spread this badly chosen
> name from options to config variables, does it?  I think that if we
> are going to define a new config variable today, then it should be
> named properly, and it's better not to call it 'commit.verbose', but
> 'commit.showDiff' or something.  Perhaps we could even define two new
> config variables: 'commit.showDiff' for the diff of the changes to be
> committed (= '-v'), and 'commit.showUnstagedDiff' for the - wait for
> it! - unstaged changes (= '-v -v').  Not sure about the variable
> names, though, because "plain" 'git diff' shows unstaged changes,
> while 'git diff --cached' shows staged changes.

>
> Furthermore, it doesn't mean that we can't add properly named command
> line option(s) and state that '-v|--verbose' is a synonym to
> '--show-diff' (maybe even deprecate '--verbose'), but I don't want to
> squeeze even more into a GSOC micro project.