Re: [RFH] convert shortlog to use parse_options

["Kristian Høgsberg" <krh@redhat.com>]

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:
> > On Thu, Dec 13, 2007 at 05:40:23PM +0000, Junio C Hamano wrote:
> > > Pierre Habouzit <madcoder@debian.org> writes:
> > > 
> > > > 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