On 03/13, Stefan Beller wrote: > + 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 <bmwill@xxxxxxxxxx> 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? yeah this patch introduces a change to the documentation for URL to indicate the change. -- Brandon Williams