The problem is with other tools that use git, like Swift Package Manager - https://swift.org/package-manager/. Versions of git before 2.9.0 have no option --no-shallow-submodules. So the tools that use git would have to check if the version of git is greater than or equal 2.9.0 to know to specify that option.
Best Regards, Vadim Jeff King <p...@peff.net> wrote on 06/19/2016 01:00:51 PM: > From: Jeff King <p...@peff.net> > To: Vadim Eisenberg/Haifa/IBM@IBMIL > Cc: Stefan Beller <sbel...@google.com>, git@vger.kernel.org > Date: 06/19/2016 01:01 PM > Subject: Re: [BUG REPORT] git 2.9.0 clone --recursive fails on > cloning a submodule > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
