Re: regression AGAIN in output of git-pull --rebase --recurse-submodules=yes --quiet

From: Duy Nguyen <pclouds@gmail.com>
Date: Apr 16, 2019, 07:48 UTC
Message-ID: <CACsJy8AasZkzkR4apr1cywi1wpP92FOjAN2Oc7GYDYv4NPnXdQ@mail.gmail.com>
In-Reply-To: <CAODn77oL6sj5zvxgPGw=4TNqmnSeBq4=j2r2nx_51YHooECo7w@mail.gmail.com>

On Tue, Apr 16, 2019 at 1:31 PM Paul Morelle <paul.morelle@gmail.com> wrote:

Show 11 quoted lines

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