From: Morian Sonnet <moriansonnet@gmail.com>
Date: Mon, 24 Jun 2019 20:26:53 GMT
Subject: submodule foreach: fix recursion of options
Message-ID: <20190624202653.13810-1-MorianSonnet@googlemail.com>
In-Reply-To: <xmqqsgryhmqt.fsf@gitster-ct.c.googlers.com>

Hi Junio,

thanks for your comments.

I fixed the type in the commit message and adapted my test case to the
required shell script style.

Best regards,
   Morian


Junio C Hamano <gitser@pobox.com> writes:

> > Calling
> >
> >     git submodule foreach --recursive <subcommand> --<option>
> >
> > leads to an error stating that the option --<option> is unknown to
> > submodule--helper. That is of course only, when <option> is not a valid
> > option for git submodule foreach.
> >
> > The reason for this is, that above call is internally translated into a
> > call to submodule--helper:
> >
> >     git submodule--helper foreach --recursive \
> >         -- <subcommand> --<option>
> >
> > This call starts by executing the subcommand with its option inside the
> > first first level submodule and continues by calling the next iteration
> 
> first first???
> 
> > of the submodule foreach call
> >
> >     git --super-prefix <submodulepath> submodule--helper \
> >       foreach --recursive <subcommand> --<option>
> >
> > inside the first level submodule. Note that the double dash in front of
> > the subcommand is missing.
> >
> > This problem starts to arise only recently, as the
> > PARSE_OPT_KEEP_UNKNOWN flag for the argument parsing of git submodule
> > foreach was removed in commit a282f5a906. Hence, the unknown option is
> > complained about now, as the argument parsing is not properly ended by
> > the double dash.
> >
> > This commit fixes the problem by adding the double dash in front of the
> > subcommand during the recursion.
> >
> > Signed-off-by: Morian Sonnet <moriansonnet@googlemail.com>
> > ---
> >  builtin/submodule--helper.c  | 1 +
> >  t/t7407-submodule-foreach.sh | 7 +++++++
> >  2 files changed, 8 insertions(+)
> >
> > diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> > index 0bf4aa088e..afaf0819c9 100644
> > --- a/builtin/submodule--helper.c
> > +++ b/builtin/submodule--helper.c
> > @@ -540,6 +540,7 @@ static void runcommand_in_submodule_cb(const struct cache_entry *list_item,
> >  		if (info->quiet)
> >  			argv_array_push(&cpr.args, "--quiet");
> >  
> > +		argv_array_push(&cpr.args, "--");
> >  		argv_array_pushv(&cpr.args, info->argv);
> >  
> >  		if (run_command(&cpr))
> > diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
> > index 706ae762e0..43da184d40 100755
> > --- a/t/t7407-submodule-foreach.sh
> > +++ b/t/t7407-submodule-foreach.sh
> > @@ -421,4 +421,11 @@ test_expect_success 'option-like arguments passed to foreach commands are not lo
> >  	test_cmp expected actual
> >  '
> >  
> > +test_expect_success 'option-like arguments passed to foreach recurse correctly' '
> > +  git -C clone2 submodule foreach --recursive "echo be --an-option" > expected &&
> > +  git -C clone2 submodule foreach --recursive echo be --an-option > actual &&
> > +  grep -e "--an-option" expected &&
> > +  test_cmp expected actual
> > +'
> 
> Some shell style nits.
> 
>  - our shell scripts use HT for indentation, not two SPs.
> 
>  - there is one SP before a redirection operator (you did it
>    correctly), and no SP after a redirection operator before the
>    target filename.
> 
>  - mostly we prepare the right answer in 'expect' and take the
>    output from tested command in 'actual' to compare.  There are a
>    few 'expected' in this test file already, so you are not
>    introducing a new inconsistency, but you are making things
>    worse.  Don't.
> 
> Other than that, your fix looks quite nicely described and executed.
> 
> Thanks.