Æ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 support
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.e. as long as "status" is optional it would make sense to support
all of its options when it's omitted, but we only do that with
"--quiet" and "--cached", and curiously omit "--recursive".

Ah! Okay, this finally makes sense to me now. The usage strings in
Documentation/git-submodule.txt and git-submodule.sh document both
"--quiet" and "--cached", but that's bogus because we should either:

- pretend that "git submodule" doesn't default to "status", so we
  should omit "--cached", or
- be clearer that "git submodule" _does_ default to "status", so we
  should include "--recursive"

Now that we've acknowledged the existence of top-level "--recursive", we
should probably amend the usage strings. To be honest, I think a less
confusing, more consistent direction would be to just drop this "default
to status" behavior but I doubt we can do that any time soon..