Roy Eldar <royeldar0@xxxxxxxxx> writes:
> When git-submodule.sh parses various options and switchs, it sets some
> variables to values; in particular, every switch that is passed causes a
> corresponding variable to be set to 1, which then affects the options
> given to git-submodule--helper.
>
> There are some variables are assigned "$1", although there is no reason
> for it; this was actually noticed in 757d092 for the "$cached" variable.
Wearing devil's advocate hat on.
This can cut both ways. If you are doing a thin wrapper front-end,
when calling into the underlying machinery that has its own option
parser, it is often easier to write and read
submodule--helper $force $cached
instead of
submodule--helper ${force:+--force} ${cached:+--cached}
In addition, when debugging such a script by running it under "sh -x",
a typical construct like
if test "$force" = 1
then
... do the force thing ...
would appear in the "-x" trace as
+test 1 = 1
+... do the force thing ...
if you force yourself to use "1", but
if test "$force" = "--force"
then
... do the force thing ...
would show either
+test --force = --force
or
+test "" = --force
and the latter is especially useful when you are wondering why the
"--force" you gave from the command line is not taking effect.
Having said all that, as long as the use of these switch variables
are done consistently (e.g., consistently set effective ones to "1",
and consistently set ones that are off to ""), we are OK.
Thanks.
