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*].
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.
[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?
