here comes the next version. > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > Hi Morian, > > On Sat, 22 Jun 2019, Morian Sonnet wrote: > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > > > On Tue, 18 Jun 2019, Morian Sonnet wrote: > > > > > > > "Morian Sonnet via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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
