On 02/24, Junio C Hamano wrote: > Brandon Williams <bmw...@google.com> writes: > > > Currently the submodule.<name>.url config option is used to determine > > if a given submodule exists and is interesting to the user. This > > however doesn't work very well because the URL is a config option for > > the scope of a repository, whereas the existence of a submodule is an > > option scoped to the working tree. > > > > In a future with worktree support for submodules, there will be multiple > > working trees, each of which may only need a subset of the submodules > > checked out. The URL (which is where the submodule repository can be > > obtained) should not differ between different working trees. > > > > It may also be convenient for users to more easily specify groups of > > submodules they are interested in as apposed to running "git submodule > > init <path>" on each submodule they want checked out in their working > > tree. > > > > To this end, the config option submodule.active is introduced which > > holds a pathspec that specifies which submodules should exist in the > > working tree. > > Hmph. submodule.active in .git/config would be shared the same way > submodule.<name>.url in .git/config is shared across the worktrees > that stems from the same primary repository, no? > > Perhaps there are some other uses of this submodule.active idea, but > I do not see how it is relevant to solving "multiple worktrees" > issue. Per-worktree config would solve it with the current > submodule.<name>.url without submodule.active list, I would think [*1*].
Correct, I should update the language to indicate this allows the URL to be shared between worktrees, but a per-worktree config must exist before submodule.active can actually be used to select different groups of submodules per-worktree. The idea is that if submodule.active is set then you no longer look at the URLs to see what is interesting but rather at the paths. > 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. > > > > [Footnote] > > *1* At the conceptual level, I agree that .url that also means "we > are interested in this one" feels like somewhat an unclean > design, but that is not what you are "fixing", is it? > -- Brandon Williams
