submodule foreach: fix recursion of options

[Morian Sonnet <moriansonnet@gmail.com>]

here comes the next version.

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> Hi Morian,
> 
> On Sat, 22 Jun 2019, Morian Sonnet wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > On Tue, 18 Jun 2019, Morian Sonnet wrote:
> > >
> > > > "Morian Sonnet via GitGitGadget" <gitgitgadget@gmail.com> wrote:
> > > >
> > > > > Calling
> > > > >
> > > > >     git submodule foreach --recursive git reset --hard
> > > > >
> > > > > leads to an error stating that the option --hard is unknown to
> > > > > submodule--helper.
> > > > >
> > > > > Reasons:
> > > > >
> > > > > . Above call is internally translated into
> > > > >
> > > > >     git submodule--helper foreach --recursive -- git reset --hard
> > > > >
> > > > > . After calling
> > > > >
> > > > >     git reset --hard
> > > > >
> > > > >   inside the first first level submodule,
> > > > >
> > > > >     git --super-prefix <submodulepath> submodule--helper \
> > > > >       foreach --recursive git reset --hard
> > > > >
> > > > >   is called. Note the missing --.
> > > > >
> > > > > . Due to the removal of PARSE_OPT_KEEP_UNKNOWN in commit a282f5a906 the
> > > > >   option --hard is not passed to
> > > > >
> > > > >     git reset
> > > > >
> > > > >   anymore, but leads to git submodule--helper complaining about an
> > > > >   unknown option.
> > > > >
> > > > > Fix:
> > > > >
> > > > > . Add -- before the command to execute, such that now correctly
> > > > >
> > > > >     git --super-prefix <submodulepath> submodule--helper \
> > > > >       foreach --recursive -- git reset --hard
> > > > >
> > > > >   is called.
> > >
> > > This is a good explanation, even if the format is not exactly close to the
> > > existing commit messages ;-) If you look e.g. at
> > > https://github.com/git/git/commit/e5a329a279c7, you will see what I mean:
> > > there is much more "prose" (and less bullet points) going on.
> >
> > Ok, I see the differences. Shall I adapt the commit description?
> 
> Well, I would if I were you ;-)

Ok, done.

> 
> > My test so far was designed to not actually check whether git reset
> > --hard has shown any effect.
> 
> Right, but the test case's title suggested that...

The commit message is very specific regarding git reset --hard, right.
Changed that.

> 
> > Taking the test "test "foreach --quiet --recursive"" and the test
> > "option-like arguments passed to foreach commands are not lost" for
> > example, I suggest the following:
> >
> >   git -C clone2 submodule foreach --recursive "echo be --hard" > expected &&
> >   git -C clone2 submodule foreach --recursive echo be --hard > actual &&
> >   grep -sq -e "--hard" expected &&
> 
> Please without the `-sq`.

Oh, ok, i took it from another test in that suite.

> 
> >   test_cmp expected actual
> 
> Sounds good to me, especially with this suggestion:
> 
> > As final comment: One could change the flag --hard to something which
> > will definetely never be an option flag for both, echo and git submodule
> > foreach, e.g.  --this-will-never-be-an-option.
> 
> Personally, I'd go for `echo --an-option`, and yes, you are absolutely
> right, the intention of your bug fix is not so much to fix the recursive
> `git reset --hard` as it is to fix _any_ recursive command with
> command-line options.
> 
> To be honest, I had missed that `git submodule foreach --recursive`
> executes commands even in uninitialized submodules... I could even see how
> some users might consider that behavior a bug... are you sure this is the
> case? Is this `echo` really executed even in `nested2`?

I think this is a misunderstanding. I did not mean that the subcommand
is executed in `nested2` (which it actually is not) but rather that
`git submodule--helper foreach ...`
is again executed in `nested1` and this even if `nested1` does not
include any submodules.

Best regards,
  Morian