Re: [RFH] convert shortlog to use parse_options

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

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