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 <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?

yeah this patch introduces a change to the documentation for URL to
indicate the change.

-- 
Brandon Williams

Reply via email to