On Sun, Jun 19, 2016 at 10:17:36AM +0300, Vadim Eisenberg wrote: > /usr/local/bin/git clone --recursive --depth 10 > https://github.com/IBM-Swift/Kitura-net.git > Cloning into 'Kitura-net'... > remote: Counting objects: 253, done. > remote: Compressing objects: 100% (142/142), done. > remote: Total 253 (delta 134), reused 188 (delta 86), pack-reused 0 > Receiving objects: 100% (253/253), 63.28 KiB | 0 bytes/s, done. > Resolving deltas: 100% (134/134), done. > Checking connectivity... done. > Submodule 'Kitura-Build' (https://github.com/IBM-Swift/Kitura-Build.git) > registered for path 'Kitura-Build' > Cloning into '/home/vadime/Kitura-net/Kitura-Build'... > error: no such remote ref d0d9d6c739a79627641e6438fe4f39bd0eba83bb > Fetched in submodule path 'Kitura-Build', but it did not contain > d0d9d6c739a79627641e6438fe4f39bd0eba83bb. Direct fetching of that commit > failed. The problem seems to be the shallow clone. The super-project points to a commit in the submodule that is not near the tip of any branch, so shallow-cloning the submodule means we don't get that commit. Prior to d22eb04 (clone: add `--shallow-submodules` flag, 2016-04-25), submodules were _always_ cloned fully. The immediate workaround is to add "--no-shallow-submodules" to your clone invocation. Stefan, I think it might be worth revisiting the default set by d22eb04 to propagate shallowness from the super-project clone. In an ideal world, we would be asking each submodule for the actual commit we are interested in, and shallowness would not matter. But until uploadpack.allowReachableSHA1InWant works everywhere, I suspect this is going to be a problem. -Peff -- 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