On Tue, Apr 16, 2019 at 1:31 PM Paul Morelle <[email protected]> wrote: >> The problem here is the option parser of this command would try to >> parse all options, so it considers both --quiet the same thing and are >> to tell "submodule--foreach" to be quiet, the second --quiet is not >> part of the "git pull" command anymore. >> >> So the fix would be to pass "--" to stop option parsing. >> submodule--helper should not parse options it does not understand >> anyway. Something like this should work. > > > My expectation as a user (and probably Robin's too) would be that `git > submodule foreach` stops parsing arguments at `--` or at the first > not-recognized argument, whichever is encountered first. The rest of the > arguments would then be considered as the command.
I don't think I change any visible behavior though (or at least trying not to). There are two command line parsers, the "front" one is in git-submodule.sh and should do what you describe (or whatever the current behavior is) and there's an internal one for "git submodule--helper" which is more like internal API than anything. The change here is to stop the internal parser from accidentally interpret options that belong to the foreach's command. The "--" and first non-recognized argument should be handled correctly by the front parser. The exact behavior of this front parser, I can't tell (I'm nowhere near expert level of submodules) but yeah it should stop at either `--` or the first non-option argument (e.g. something that does not start with '-'). An argument that looks like an option (i.e. starts with '-') but not recognized should result in an error. This is pretty much standard behavior for all other commands, but I have not tested this with git-submodule.sh. > This would slightly break the retrocompatibility, but would also avoid > similar bugs in the future. -- Duy
