Am 11.11.2010 19:31, schrieb Junio C Hamano: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > >>> "fetch.recurseSubmodules" is only read from .git/config. The one read >>> first from .gitmodules and then from .git/config is the per-submodule >>> setting "submodule.<name>.fetchRecurseSubmodules" added in 3/3. >> >> Sorry for the nonsense. Would it be easy (or desirable) to make >> _that_ one not be read from .gitmodules? > > I think the motivation behind having a way to read it from .gitmodules is > so that project can suggest the default for convenience (e.g. "almost > everybody who interacts with this project wants these submodules checked > out and kept updated"). Yes, and to achieve that it should /not/ be necessary to run a "git submodule sync" manually afterwards to activate those changes. Jonathan, I think when we allow upstream to configure which submodules are to be cloned and checked out by default (which seems an option almost everyone likes to have), doesn't it make sense to let upstream set a default which submodules should be fetched too (so that new commits there can be checked out recursively later)? I would rather not like to do that implicitly just because a submodule is configured for recursive checkout ... > Traditionally the suggestions kept in .gitmodules were propagated to the > config when the submodule was initialized, and at runtime we read only > from the config from then on without reading from .gitmodules, so that > once the user decides to follow what the project suggests (or customize > that away), the preference would stick to the repository. > > That arrangement does not cater well to people who want to follow along > whatever the project's suggestion of the day, so we might want to change > things so that we if we find it in the config, we stop there and use what > we found, otherwise we use what is in the in-tree gitmodules; I suspect we > might require some changes to "submodule init" not to copy certain things > to the config for that to work, though... Right. But this would enable you to have branches where different sets of submodules are fetched, checked out and/or considered to make the superproject dirty depending on the topic the branch is for. -- 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