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

[Nicolas Vigier <boklm@mars-attacks.org>]

On Wed, 16 Oct 2013, Johannes Sixt wrote:

> Am 10/16/2013 1:57, schrieb Jonathan Nieder:
> > Junio C Hamano wrote:
> > 
> >> You just made these two that the user clearly meant to express two
> >> different things indistinguishable.
> >>
> >> 	opt.sh -S
> >>       opt.sh -S ''
> > [...]
> >> And that is exactly why gitcli.txt tells users to use the 'sticked'
> >> form, and ends the bullet point with:
> >>
> >>    An option that takes optional option-argument must be written in
> >>    the 'sticked' form.
> > 
> > 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?

The later, as optional arguments needs to be sticked, but I think this
is not related to the problems with --parseopt.

Here is a summary the problems I think we have with --parseopt and
proposed solutions. This command makes it possible to parse arguments
with a loop like this :

  while test $# != 0
  do
        case "$1" in
        -q)
                GIT_QUIET=t ;;
        -S)
                # do something with $2
                # shift if you think $2 is an optional arg
                ;;
        --)
                shift; break ;;
        esac
        shift
  done
  # do something with the other arguments

And I think the problems with the '?' flag when using this kind of loop
are :

 - You don't know if $2 is the optional argument for -S, or the next option
 
 - You can't use '--' as an optional argument to -S, because you don't
   know if '--' is the optional argument to -S, or the separator between
   options and non options.

To fix this, solution 1) is to always include the optional argument in
$2, and set it to '' if it is not set. However this brings the problem
that you can't distinguish between unset argument and empty argument.
The following two become the same :
  ./opt.sh --gpg-id
  ./opt.sh --gpg-id=

Solution 2) is to use a flag like ?<default> as suggested by Jonathan.
Now you can distinguish between unset and empty args, but you can't
between <default> and unset, but this is probably not a big problem as
you can select <default> so that it is a value nobody would want to use.

Solution 3) is the OPTIONS_LONG_STICKED output format suggested by
Jonathan. I can't see any problem with this one.