]> git.ipfire.org Git - thirdparty/git.git/commit
clone: use "quick" lookup while following tags
authorJeff King <peff@peff.net>
Wed, 1 Apr 2020 12:15:37 +0000 (08:15 -0400)
committerJunio C Hamano <gitster@pobox.com>
Wed, 1 Apr 2020 16:56:41 +0000 (09:56 -0700)
commit167a575e2db8e6e4e95fe53889258c16f35ac7f9
tree61629ad7f8fadb246eb16b157914775098dbb59d
parent3e96c66805f17d7345eba4733bc80c6fe646b95f
clone: use "quick" lookup while following tags

When cloning with --single-branch, we implement git-fetch's usual
tag-following behavior, grabbing any tag objects that point to objects
we have locally.

When we're a partial clone, though, our has_object_file() check will
actually lazy-fetch each tag. That not only defeats the purpose of
--single-branch, but it does it incredibly slowly, potentially kicking
off a new fetch for each tag. This is even worse for a shallow clone,
which implies --single-branch, because even tags which are supersets of
each other will be fetched individually.

We can fix this by passing OBJECT_INFO_SKIP_FETCH_OBJECT to the call,
which is what git-fetch does in this case.

Likewise, let's include OBJECT_INFO_QUICK, as that's what git-fetch
does. The rationale is discussed in 5827a03545 (fetch: use "quick"
has_sha1_file for tag following, 2016-10-13), but here the tradeoff
would apply even more so because clone is very unlikely to be racing
with another process repacking our newly-created repository.

This may provide a very small speedup even in the non-partial case case,
as we'd avoid calling reprepare_packed_git() for each tag (though in
practice, we'd only have a single packfile, so that reprepare should be
quite cheap).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/clone.c
t/t5616-partial-clone.sh