On Tue, Jun 06, 2017 at 11:10:24AM -0700, Brandon Williams wrote: > > > 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. OK, thanks for the explanation. I certainly agree that treating .gitmodules as the source of truth is consistent and easy to explain. I'll update my test to handle the new behavior (it's a regression test for how GitHub Pages handles some broken setups). -Peff