On Mon, Jun 5, 2017 at 8:56 PM, Jeff King <peff@xxxxxxxx> wrote: > While running some regression tests with v2.13, I noticed an odd > behavior. If I create a repository where there's a gitlink with no > matching .gitmodules entry: > > git init repo > cd repo > n10=1234abcdef > n40=$n10$n10$n10$n10 > git update-index --add --cacheinfo 160000 $n40 foo > git commit -m "gitlink without .gitmodule entry" > > and then I clone it recursively with v2.12, it fails: > > $ git.v2.12.3 clone --recurse-submodules . dst; echo exit=$? > Cloning into 'dst'... > done. > fatal: No url found for submodule path 'foo' in .gitmodules > exit=128 > > But with v2.13, it silently ignores the submodule: > > $ git.v2.13.1 clone --recurse-submodules . dst; echo exit=$? > Cloning into 'dst'... > done. > exit=0 > > 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) > I also wasn't sure if this might be intentional. I.e., that we'd just > consider gitlink entries which aren't even configured as not-submodules > and ignore them. I think this is what we want to do, and we should do it consistently. The only downside for this is that more unintentional gitlinks may be added to repositories as Git will be very good at ignoring them. > I couldn't certainly see an argument for moving in that > direction, but it is different than what we used to do. But I couldn't > find anything in any of the commit messages that mentioned this either > way, so I figured I'd punt and ask. :) Yeah, yesterday we had a big discussion if we want to publish our roadmap and long term vision (as a team, as a company, or as a community?) This would help newcomers and outsiders to see where e.g. submodules are headed and people could speak up early if we miss their use case. Thanks for asking, Stefan > > -Peff