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

From: Jeff King <peff@peff.net>
Date: Oct 16, 2013, 08:53 UTC
Message-ID: <20131016085316.GA31314@sigill.intra.peff.net>
In-Reply-To: <525E3A80.5000500@viscovery.net>

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

Show 9 quoted lines

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