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

[Junio C Hamano <gitster@pobox.com>]

Roy Eldar <royeldar0@gmail.com> writes:

> When we run "git submodule", the script parses the various options and
> then invokes "git-submodule--helper". Unlike most builtin git commands
> which parse short/long options using parse-options.c, the parsing of
> arguments is completely done within git-submodule.sh; therefore, there
> are some inconsistencies with the rest of the commands, in particular
> the parsing of option arguments given to various options.
>
> Improve the handling of option arguments for both long & short options;
> for example, passing flags such as "--branch=master" or "-j8" now works.
>
> Changes since v1:
>
> - Make variable values always contain the option name.
> - Rename a couple of variables in order to improve consistency.

After reading this, it was confusing to see [1/8] still doing "1 or
empty" boolean, only to be further modified in [7/8].  We prefer to
see a single series stumbling in the middle and changing the course.

Just a tangent.

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.





> Link to v1:
>
> https://lore.kernel.org/git/20241207135201.2536-1-royeldar0@gmail.com
>
> Roy Eldar (8):
>   git-submodule.sh: make some variables boolean
>   git-submodule.sh: improve parsing of some long options
>   git-submodule.sh: improve parsing of short options
>   git-submodule.sh: get rid of isnumber
>   git-submodule.sh: get rid of unused variable
>   git-submodule.sh: add some comments
>   git-submodule.sh: improve variables readability
>   git-submodule.sh: rename some variables
>
>  git-submodule.sh | 214 +++++++++++++++++++++++------------------------
>  1 file changed, 104 insertions(+), 110 deletions(-)