The logic in t3040-subprojects-basic.sh assumes that comparing the output of 'git-ls-files -s' when run in the original superproject and when run in the cloned superproject is a good test that cloning worked. However, the output of git-ls-files does not include the files in subprojects, so this test passes, even though the clone contains only the directories of the subprojects and none of their containing files or .git subdirectories. In other words, given this: superproject sub1 Makefile sub2 Makefile when somebody does `git-clone superproject', I believe they expect to get the same tree. Instead, they get this: superproject sub1 sub2 Note that `git-clone superproject/sub1` works as expected, but this sequence fails: git-clone superproject foo cd foo git-clone ../superproject/sub1 As does this sequence: git-clone superproject foo cd foo/sub1 git-pull ../superproject/sub1 So there is no way that I can see to actually clone a project that has subprojects. Is this intentional? Shouldn't clone get the entire superproject? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
