Re: how optparse can go horribly wrong

From: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
Date: Sep 26, 2009, 01:51 UTC
Message-ID: <20090926015127.GA12994@vidovic>
In-Reply-To: <20090925233226.GC14660@spearce.org>

The 25/09/09, Shawn O. Pearce wrote:

Show 13 quoted lines

> *sigh*.  Someone just ran into this today:
> 
>   $ git commit -a -ammend
>   [work ce38944] mend
>    1 files changed, 2 insertions(+), 0 deletions(-)
> 
> Omit one - and include an extra 'm', and instead of --amend you
> have -a -m mend.  Which isn't exactly what you wanted.
> 
> We do catch -amend with an error though:
> 
>   $ git commit -amend
>   error: did you mean `--amend` (with two dashes ?)

OTOH, this is a bit odd because a commit with the message "end" makes perfect sense for a "fast and crappy commit local workflow".

And we allow -ammend (with two 'm')

  $ git commit -ammend
  [next 101f014] mend
   1 files changed, 1 insertions(+), 0 deletions(-)
  $

> I wonder, should the -m flag on commit not allow cuddling its
> value against the switch when its combined in short form with
> other switches?

Doing this only to -m flag would break consistency. That said, I don't have any opinion in disallowing the sticked form for _all_ short options.

-- 
Nicolas Sebrecht