Jeff King <p...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
