Re: [PATCH v5 2/2] submodule: pass on http.extraheader config settings

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> Keep in mind that submodule interactions may be triggered from other
> non-submodule commands. So "git fetch", for instance, may end up caring
> about whether you pass "http.*" or "credential.*" down to the
> submodules.

> I do not think "fetch" should grow submodule-specific
> options,...

The updated "git fetch" needs to grow submodule-specific options to
at least either enable or disable "recurse into submodules", and
that is true even if the default behaviour in the future were to
recurse into submodules in a top-level project repository that has
submodules (i.e. you must have "git fetch --no-recurse-submodules"
option).  "Please use these configuration when you do recurse into
them" options are very much submodule specific in the same way.

If anything, with Stefan's "submodule groups" thing, I would expect
more commands (like "git diff") to become aware of the possibility
of descending into submodules (and even "selected subset of
submodules"), and they need command line options to tell which ones
to descend into.  "Here is the set of submodules I want you to
descend into" and "By the way, I want you to use these settings
while working in them" would go naturally hand in hand, I would
imagine, so I strongly disagree with the statement "fetch should not
grow submodule specific options".

Of course, we can stop teaching --recurse-submodules to non "git
submodule" commands and concentrate on improving "git submodule" as
the end-user facing command, or cover usecases to work on subset of
submodules with "git submodule foreach".  But I do not think that is
what you are advocating for.