Ævar Arnfjörð Bjarmason [off-list ref] writes:

Test what exit code and output we emit on "git submodule -h", how we
handle "--" when no subcommand is specified, and how the top-level
"--recursive" option is handled.

For "-h" this doesn't make sense, but let's test for it so that any
subsequent eventual behavior change will become clear.

For "--" this follows up on 68cabbfda36 (submodule: document default
behavior, 2019-02-15) and tests that "status" doesn't don't support

s/doesn't don't/doesn't/ I assume ;)

the "--" delimiter. There's no intrinsically good reason not to
support that. We behave this way due to edge cases in
git-submodule.sh's implementation, but as with "-h" let's assert our
current long-standing behavior for now.

For "--recursive" the exclusion of it from the top-level appears to
have been an omission in 15fc56a8536 (git submodule foreach: Add
--recursive to recurse into nested submodules, 2009-08-19), there
doesn't seem to be a reason not to support it alongside "--quiet" and
"--cached", but let's likewise assert our existing behavior for now.

I think my original comment isn't directly addressed here:

  I'm not sure about this one. "--recursive" isn't a top level option, and
  15fc56a8536 doesn't seem to suggest that it was meant to be one (but I
  did realize that git-submodule.txt documents all of the options to all
  subcommands, which is very confusing.)

But maybe I'm mistaken and it's somewhere. Do we know whether
"--recursive" was always intended to be top-level?

The changes themselves look good :)

-- 
2.37.1.1233.ge8b09efaedc