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). 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 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. :) -Peff
