Re: [PATCH v2 1/1] submodule foreach: fix recursion of options

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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 ;-)

> 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...

> 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`.

> 	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`?

Ciao,
Johannes