Re: [PATCH] rev-parse --parseopt: fix handling of optional arguments

[Jeff King <peff@peff.net>]

On Wed, Oct 16, 2013 at 09:04:32AM +0200, Johannes Sixt wrote:

> > Yes, another possibility in that vein would be to teach rev-parse
> > --parseopt an OPTIONS_LONG_STICKED output format, and then parse with
> 
> Aren't you people trying to solve something that can't besolved? What does
> 
>   git commit -S LICENSE
> 
> mean? Commit the index and sign with the key-id "LICENSE" or commit just
> the file "LICENSE" with the default key-id?

It means the latter. Because the argument is optional, you must use the
"sticked" form:

  git commit -SLICENSE

If the caller does not know whether the argument is optional or not,
they should use the sticked form to be on the safe side.

The problem, as I understand it, arises from the fact that shell scripts
can use "git rev-parse --parseopt" to check and normalize their
arguments. So for example:

  # pretend we got "-bs" on our command line
  set -- -bs

  git rev-parse --parseopt -- "$@" <<\EOF
  usage...
  --
  b!    the "b" option
  s!    the "s" option
  EOF

would produce:

  set -- -b -s --

The latter is much easier to parse in the shell, because options are
split, it ends with "--", etc. But what is the normalized form for an
optional argument? It either needs to be consistently "sticked" or
"unsticked", either:

  set -- -S '' --     ;# default
  set -- -S 'foo' --  ;# not default

or

  set -- -S --    ;# default
  set -- -Sfoo -- ;# not default

so that reading the normalized form is unambiguous.

-Peff