Re: [RFH] convert shortlog to use parse_options

From: Pierre Habouzit <madcoder@debian.org>
Date: Dec 13, 2007, 18:03 UTC
Message-ID: <20071213180347.GE1224@artemis.madism.org>
In-Reply-To: <7vbq8u4ho8.fsf@gitster.siamese.dyndns.org>

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

Show 26 quoted lines

> 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.

  *I* (and it's my opinion, maybe other don't see it that way) see the
parse-option module as a convenience given to people using the CLI UI in
an interactive shell. So it tries to achieve a good balance between
brevity and error detection. Here I think it's quite error prone and
gives almost no help to the user: if there is a gain to type git repack
-afd vs. git repack -a -f -d, I see no real gain in --abbrev 10 vs.
--abbrev=10.

  [0] OTOH I'm not sure there will ever be optional arguments that
      aren't integers in git, but I may be wrong.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org