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

From: Roy E <royeldar0@gmail.com>
Date: Dec 11, 2024, 06:13 UTC
Message-ID: <CAOfFam=_G=EPkw-fCQD___gFc3U7rwnVr_uteKG9-USK8=veRA@mail.gmail.com>
In-Reply-To: <xmqqikrrjdds.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> Just to make sure we are on the same page,
>
>     --foo "hello world"
>
> is an example of an option "foo" that takes exactly one argument, a
> string which happens to have a whitespace in it, and is an example
> for which "variable has the dash-dash option, equals, and its value"
> pattern would not work well.

I'm not sure why then this pattern would not work; when the argument is passed to the option in this case, we set the variable to "--foo=$2", so it should be fine (like you've written below).

Show 9 quoted lines

> If we can pass it as
>
>     --foo="hello world"
>
> then we are safe, as we can do
>
>         foo="--foo=hello world"
>         ... later ...
>         git cmd ${foo:+"$foo"}

All of the options with arguments of git-submodule--helper can be passed as "--foo=...", and spaces (or other misc characters) that appear in the option value shouldn't pose any problem whatsoever; the logic in parse-options.c::parse_long_opt confirms that.