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