+ cc Jens, FYI. Once upon a time I brought up different addressing/activating mechanism for submodules and I remember Jens having some uneasy thoughts about that back in the day. This series addresses the user confusion and documentation better than what I had back then.
On Mon, Mar 13, 2017 at 2:43 PM, Brandon Williams <bmw...@google.com> wrote: > 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 two config options are introduced, submodule.active and > submodule.<name>.active. The submodule.active config holds a pathspec > that specifies which submodules should exist in the working tree. The > submodule.<name>.active config is a boolean flag used to indicate if > that particular submodule should exist in the working tree. > > Given these multiple ways to check for a submodule's existence the more > fine-grained submodule.<name>.active option has the highest order of > precedence followed by the pathspec check against submodule.active. To > ensure backwards compatibility, if neither of these options are set git > falls back to checking the submodule.<name>.url option to determine a > submodule's existence. > > > +submodule.<name>.active:: > + Boolean value indicating if the submodule is of interest to git > + commands. This config option takes precedence over the > + submodule.active config option. ... which itself takes precedence over the (deprecated) .URL We conveniently do not talk about the URL here anymore. But! We need to change submodule.<name>.URL now?
