New in the upcoming git1.8.4 (July 2013):
git submodule update" can optionally clone the submodule repositories shallowly.
--depthoption to the add and update commands of "git submodule", which is then passed on to the clone command. This is useful when the submodule(s) are huge and you're not really interested in anything but the latest commit.
Tests are added and some indention adjustments were made to conform to the rest of the testfile on "submodule update can handle symbolic links in pwd".
Signed-off-by: Fredrik Gustafsson
Acked-by: Jens Lehmann
That means this works:
git submodule add --depth 1 -- repository path git submodule update --depth -- [<path>...]
This option is valid for
Create a 'shallow' clone with a history truncated to the specified number of revisions.
As far as I can tell this option isn't usable for submodules which don't track
mastervery closely. If you set depth 1, then
submodule updatecan only ever succeed if the submodule commit you want is the latest master. Otherwise you get "
fatal: reference is not a tree".
That is true.
That is, until git 2.8 (March 2016). With 2.8, the
submodule update --depth has one more chance to succeed, even if the SHA1 is directly reachable from one of the remote repo HEADs.
submodule: try harder to fetch needed sha1 by direct fetching sha1
When reviewing a change that also updates a submodule in Gerrit, a common review practice is to download and cherry-pick the patch locally to test it.
However when testing it locally, the '
git submodule update' may fail fetching the correct submodule sha1 as the corresponding commit in the submodule is not yet part of the project history, but also just a proposed change.
$sha1was not part of the default fetch, we try to fetch the
$sha1directly. Some servers however do not support direct fetch by sha1, which leads
git-fetchto fail quickly.
We can fail ourselves here as the still missing sha1 would lead to a failure later in the checkout stage anyway, so failing here is as good as we can get.
It would seem to me that commit fb43e31 requests the missing commit by SHA1 id, so the
uploadpack.allowTipSHA1InWantsettings on the server will probably affect whether this works.
I wrote a post to the git list today, pointing out how the use of shallow submodules could be made to work better for some scenarios, namely if the commit is also a tag.
Let's wait and see.
I guess this is a reason why fb43e31 made the fetch for a specific SHA1 a fallback after the fetch for the default branch.
Nevertheless, in case of “--depth 1” I think it would make sense to abort early: if none of the listed refs matches the requested one, and asking by SHA1 isn't supported by the server, then there is no point in fetching anything, since we won't be able to satisfy the submodule requirement either way.