Re: [BUG?] gitlink without .gitmodules no longer fails recursive clone

> > > This bisects to your bb62e0a99 (clone: teach --recurse-submodules to
> > > optionally take a pathspec, 2017-03-17). That patch just sets
> > > submodule.active by default, so I think the real issue is probably in
> > > a086f921a (submodule: decouple url and submodule interest, 2017-03-17).
> > 
> > It's a feature, not a bug, IMO.
> > 
> > When starting out the journey to improve submodules, one of the major
> > principle was to not interfere with gitlinks too much, as they are used in
> > ways git cannot fathom (cf git-series storing patches in gitlink form).
> > 
> > And building on that: You asked for recursing into *submodules*, not
> > into *gitlinks*. And submodules in the new Git have stronger requirements
> > w.r.t. the gitmodules file. (You have to tell us exactly how you want your
> > submodule to be treated, and we do not want to half-ass guess around
> > the shortcomings of a user not telling us about the submodule)
> 
> Just for some background on the new behavior and how this functionality
> changed: My series changed how 'submodule init' behaved if you have
> 'submodule.active' set.  Once set (like how clone --recurse does now)
> when not provided any path to a submodule, a list of 'active' submodules
> matching the 'submodule.active' pathspec will be initialized.  One of
> the requirements to be 'active' is to have an entry in the .gitmodules
> file so gitlinks without an entry in the .gitmodules file will simply be
> ignored now.