Re: [PATCH 4/5] branch: restructure -v vs. -vv

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 25, 2011, 19:02 UTC
Message-ID: <7v8vqhl3go.fsf@alter.siamese.dyndns.org>
In-Reply-To: <f471a616e4f08e729384138d8cb8afff4e9dbcbf.1314259226.git.git@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

> ahead/behind info is expensive, upstream name info cheap. Therefore,
> make -v output the upstream branch name and -vv add the ahead/behind
> info.

While I do not care too much about the end result, and I even suspect that swapping the meaning might be better at the semantic level, I do not agree with the above line of reasoning. It is not based on what the end user wants at all, but is based on how easily you can produce results.

If a relatively expensive information is what is more often wanted and the users are willing to pay the price to compute it, it is very reasonable to use short-and-sweet -v for showing only that information, and have them type -vv to ask for a less common information.

I also suspect that "ahead/behind" and "who-is-upstream" may be orthogonal and we may not tie these to degree of verbosity. Jeff's suggestion to teach these to for-each-ref may be along a similar thought.

You however may be able to argue "When the user wants A/B, s/he always wants who-is-upstream, and asking for A/B and not wanting who-is-upstream is insane". If "A/B" does not make sense without seeing "who-is-upstream", but if seeing "who-is-upstream" alone makes sense without seeing "A/B", then you can argue that these two are indeed degrees of verbosity, and it may be justifiable to make -v give "who-is-upstream", and make -vv give "A/B and who-is-upstream".

But I suspect that much more people have more than one topics cooking on top of upstream (i.e. need for A/B) than people who work with these topics based on different upstreams (i.e. need for "who-is-upstream"). People who base their topics on only one upstream do not need "who-is-upstream" to understand A/B.

I am wondering if "branch -v=<comma separated tokens>", where currently available tokens are "sha1", "upstream", "ahead/behind", is the right way to keep these orthogonal and extensible (of course you would want a shorter mnemonic). Then existing -v and -vv can be understood as aliases to:

	-v   ===  -v=sha1,ahead/behind
        -vv  ===  -v=sha1,upstream,ahead/behind

and you can naturally extend the vocabulary with "patchsame" to define your -vvv introduced in [5/5].