Re: [BUG REPORT] git 2.9.0 clone --recursive fails on cloning a submodule

From: Jeff King <peff@peff.net>
Date: Jun 19, 2016, 10:00 UTC
Message-ID: <20160619100051.GA14584@sigill.intra.peff.net>
In-Reply-To: <OFE09D48F2.D1D14F49-ONC2257FD7.00280736-C2257FD7.0028245A@notes.na.collabserv.com>

On Sun, Jun 19, 2016 at 10:17:36AM +0300, Vadim Eisenberg wrote:

Show 16 quoted lines

> /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