Stefan Beller <sbeller@xxxxxxxxxx> writes: > "submodule.$name.group" to be found in .gitmodules, maybe overwritten in > .git/config tells for each submodule its memberships of groups. > > "submodule.group" should be found in .git/config only, to tell some time > after cloning which group selection was made, such that we can check > if new submodules need to be initialized (or even automatically removed). Ahh, it wasn't clear that was what you were trying to do. If that is the case, then ... > "git submodule update" may initialze and fetch new modules if the > .gitmodules file changed their view of what "default" is. > >> The name of the operation, i.e. what is to be done to the >> chosen modules, should be orthogonal, so I do not think you should >> have "submodule.autoinitgroup" or somesuch. > > I agree there. ... I do not agree that the name of "submodule.group" variable should be neutral to the operation that is done to the groups of submodules named by the variable at all. You are recording the criteria to choose a set of submodules there in the configuration, with a plan to keep doing something to them (e.g. "they will never be left uninitialized, i.e. initialied if a new submodule is added to the set"). The name of the configuration must have something that tells what that "something" is, in order to (1) hint the purpose of specifying the group selection criteria there, and (2) allow different selection criteria to keep doning another kind of something to them and distinguish these two group selection criteria. E.g. "submodule.autoInitialize = *default !:foo" may mean all the modules in the default group (now or added in the future) except the module with name 'foo' will be initialized as needed, while "submodule.autoDistim = *optional" may want to be defined to allow the system to automatically distim (whatever that operation is that will be added to Git in later versions) the modules in the optional group. > I am hoping we can put that in shorter options, such as > > clone --init-module=A --init-module=\*B --init-module=/C \ > --remember-init-for-tracking > > whereas: > > --remember-init-for-tracking: Submodule groups which are given > to clone will be remembered, such that each invocation of "update" > will make sure that group is fully there, i.e. new submodules in > the group will be initialized before updating. Is there a need for --no-remember-init-for-tracking? I do not think it would be useful. When the upstream adds a new module and defines it to be part of the default group _after_ you cloned with --init set to 'default', and you do not need that new module, at that point you can tweak your submodule.autoInitialize definition to exclude that new module. Tweaking submodule.autoInitialize definition to contain nothing after cloning with --init because you do not want the autoinit criteria kept in the resulting repository is merely a special case of that. So I do not think --remember-init-for-tracking is necessary. Just make it _always_ on and be done with it, I would say. -- 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