Heiko Voigt <hvoigt@xxxxxxxxxx> writes: >> That is definitely a huge semantics change. > > Ok seeing it that way. You are right. How about this? Actually I had an update to Documentation/git-submodule.txt in mind. For example, we say this for "update": Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. I know you added "yes, we earlier said this will clone missing ones and checkout, but if this configuration is set to none then none of that happens" much later in the section, but that feels backwards. Thinking about it more, I am starting to think that this backwardness may be an indication that we are describing a wrong solution to a wrong problem. Isn't the root cause of the issue that a "submodule init" without pathspec limit adds everything to .git/config, ending up with all submodules fully instantiated, and it is too easy to run such a lazy "submodule init"? If we allowed the project managers (i.e. the ones who write .gitmodules) to specify the default set of submodules to be initialized with such a "submodule init", omitting some submodules from even getting registered to the recipients' .git/config in the first place, wouldn't that solve the issue you are trying to address equally well, without anything to worry about this semantic change at all? I am trying to see if we can come up with a solution with which we do not even have to add any entry for a submodule to .git/config of the superproject, if it is "don't care" kind of submodule for the copy of the superproject repository the user has. The way in which the project managers specify that a module is not meant to be "init"ed by default may be to have "submodule.$name.update = none" in the .gitmodules file they ship, so externally there may not be huge difference from the behaviour (but not the implementation) of your patch, even though submodule.$name.update probably is not a good variable name to be used for this purpose. Another thing we may want to consider is to make .gitmodules describe submodule dependencies. If your hypothetical superproject is about a library, which consists of doc/, include/, and libsrc/ submodules, with pre-built binary perhaps shipped as part of the superproject itself, those who work on documentation may want to populate only doc/, those who are interested in using the library may want to populate only include/ and possibly doc/, and those who work on the library itself would populate include/ and libsrc/, possibly with doc/ submodules. It wouldn't make any sense to populate libsrc/ without populating include/ submodule, as the source would not be buildable without the includes. Now if we imagine that much more people are interested in using the library than working on it, it is plausible that the project may want to suggest: - Majority of people may want to omit libsrc/ submodule; and - If you populate libsrc/, then you would definitely want to populate include/ submodule. Your "submodule.libsrc.update = none" in .gitmodules can express the former, and I think it is natural to express the latter (i.e. submodule dependency) in the same file, to be propagated in the same way to the consumers. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html