On Tue, Feb 13, 2018 at 9:06 PM, Ciro Santilli <ciro.santi...@gmail.com> wrote:
> I have a git repo with large submodules, notably the Linux kernel, and
> shallow clone saves a lot of time.
> However, QEMU is also a submodule, which I don't control, and QEMU has
> submodules which don't point to commits that are not on any tag or
> branch, so:
> git clone --recurse-submodules --shallow-submodules
> currently fails with:
> error: Server does not allow request for unadvertised object
> Fetched in submodule path 'capstone', but it did not contain
> 22ead3e0bfdb87516656453336160e0a37b066bf. Direct fetching of that
> commit failed.
> on git 2.16.1.
In theory this should be easy. :)
In practice not so much, unfortunately. This is because cloning will just obtain
the latest tip of a branch (usually master). There is no mechanism in clone
to specify the exact sha1 that is wanted.
The wire protocol supports for asking exact sha1s, so that should be covered.
(Caveat: it only works if the server operator enables
uploadpack.allowReachableSHA1InWant which github has not AFAICT)
git-fetch allows to fetch arbitrary sha1, so as a workaround you can run a fetch
after the recursive clone by using "git submodule update" as that will use
fetches after the initial clone.
> Furthermore, I reproduce this locally with direct filesystem clones:
> and on GitHub, so I'm guessing it is not just the settings for a
> specific server?
> Would it be possible to make that work, or are there fundamental
> reasons why it is not possible?
The wire protocol allows for it, so it should be possible fundamentally.
There is a redesign of the wire protocol going on currently, which
could allow for a new fetch mode that allows having just one
connection, which would only negotiate on the superproject and
infer the submodule parts from the superproject.
> Here is my use case repo, at the point of the ugly workaround I'm
> having to do:
> Some more context:
> This would make some embedded people happy.
Yes, a lot of submodule users would be happy if that
issue is solved.
Thanks for reporting,