mailing list mirror (one of many)
 help / Atom feed
From: Stefan Beller <>
To: Ciro Santilli <>
Cc: git <>
Subject: Re: Can we make git clone --recurse-submodules --shallow-submodules work for commits that are not on tags or branches
Date: Wed, 14 Feb 2018 11:18:11 -0800
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Feb 13, 2018 at 9:06 PM, Ciro Santilli <> 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 git://
> currently fails with:
> error: Server does not allow request for unadvertised object
> 22ead3e0bfdb87516656453336160e0a37b066bf
> 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,

      reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14  5:06 Ciro Santilli
2018-02-14 19:18 ` Stefan Beller [this message]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox