Re: [RFH] convert shortlog to use parse_options

On Thu, 2007-12-13 at 13:28 -0500, Kristian Høgsberg wrote:

On Thu, 2007-12-13 at 19:03 +0100, Pierre Habouzit wrote:

quoted

On Thu, Dec 13, 2007 at 05:40:23PM +0000, Junio C Hamano wrote:

quoted

Pierre Habouzit [off-list ref] writes:

quoted

In fact we have kind of the issue for every single optional argument out
there:

$ git describe --abbrev HEAD
error: option `abbrev' expects a numerical value
[...]

  *ouch*

So I believe that with optional arguments we must change the way we do
things, and that we _must_ enforce the argument to be sticked in that
case.

I think "Must" is a bit too strong an expression.

	git describe --abbrev 7 HEAD
        git describe --abbrev HEAD
        git describe --abbrev=HEAD
	git describe --abbrev=7 HEAD
	git describe --abbrev

The --abbrev parser in this case could be asked with this question: "You
are on the command line.  There is a token after you.  Is it your
parameter?".

  I thought of that, but it's really convoluted and can definitely lead
to very subtle issues. The number of git commands with optional
arguments is quite low, mostly due to legacy, I don't expect _new_
commands to take optional arguments. I don't really like the ambiguity
it creates, and in some cases you just won't be able to disambiguate at
all. Here it looks nice because --abbrev takes an integer argument, and
it's likely that no branch nor reference names will be only made of
digits. Though for commands taking an optional string[0] argument this is
way more fishy.

My 

Oops, sorry about that.  I just wanted to say we shouldn't jump through
all these hoops to make the option parser support every type of option
there ever was in the git command line ui.  A lot of these were probably
decided somewhat arbitrarily by whoever implemented the command.
Instead it's an opportunity to retroactively enforce some consistency
and predictability to the various option-styles that have been
hand-rolled over time in different git commands.

Kristian