Re: [PATCH v2 0/8] git-submodule.sh: improve parsing of options

> While a simple wrapper script is generally easier to debug and read
> if $verbose variable's value is "--verbose" or "", there is a case
> where following this pattern is not a good idea.  If an option we
> are eventually going to give to the underlying command takes a
> value, the value can contain whitespace, and the option and its
> value need to be passed as two separate arguments, it is less error
> prone to use the "variable only contains the value" approach.
>
> Imagine that submodule--helper takes a "--foo" option with a greeting
> message like "hello world" in such a way.  We'd want to trigger it
> this way:
>
>         git submodule--helper --foo "hello world"
>
> as we are assuming that for some reason we need to pass them as two
> words, and
>
>         git submodule--helper --foo="hello world"
>
> is not an option.  In such a case, a wrapper script that takes such
> an optional parameter in $foo is easier to write like so
>
>         # parse
>         foo=
>         while ...
>         do
>                 case "$opt" in
>                 --foo=*)        foo="${1#--foo=}" ;;
>                 --foo)          foo=${2?"--foo without value"}; shift ;;
>                 ...
>                 esac
>                 shift
>         done
>
>         # interpolate
>         git submodule--helper ${foo:+--foo "$foo"}
>
> in order to avoid the value given to the option split at $IFS
> whitespace.  With foo='--foo="hello world"', passing it to the
> underlying command would involve use of eval and becomes error
> prone.
>
> I am assuming (but I don't use "git submodule" very often, so my
> assumption may be way off) that there is no such variable we need to
> pass, but if not, we may need to reconsider and use the "variable has
> only value of the option" for at least some of them.