Brandon Williams <bmwill@xxxxxxxxxx> writes: > On 02/24, Junio C Hamano wrote: > >> Also as a grouping measure, submodule.active that lists submodule >> paths feels hard to use. When switching between two branches in the >> superproject that have the same submodule bound at two different >> paths, who is responsible for updating submodule.active in >> superproject's config? If it were a list of submodule names, this >> objection does not apply, though. > > I agree that if you are listing every submodule path by hand then this > may not be the best approach and would be difficult to use. The idea is > that this would allow a user to set a general pathspec to identify a > group of modules they are interested in. Perhaps once attributes can be > used in pathspecs a user could group submodules by setting a particular > attribute and then submodule.active would have a value like > ":(attr:foo)" to indicate I'm interested in all submodules with the > "foo" attribute. OK. As .gitattributes is tracked just like .gitmodules in tree, the project can adjust the path pattern that matches a renamed submodule and gives it an attribute in .gitattributes in the same commit in the superproject that moves the directory to which the submodule is bound, just like it updates .gitmodules to adjust the name<->path mapping. So that plan solves my specific worry about using "path" for grouping and not "name". Thanks.