summaryrefslogtreecommitdiff
path: root/Documentation/git-merge.txt
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2020-04-01 08:15:37 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-04-01 09:56:41 -0700
commit167a575e2db8e6e4e95fe53889258c16f35ac7f9 (patch)
tree61629ad7f8fadb246eb16b157914775098dbb59d /Documentation/git-merge.txt
parentpartial-clone: avoid fetching when looking for objects (diff)
downloadtgif-167a575e2db8e6e4e95fe53889258c16f35ac7f9.tar.xz
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>
Diffstat (limited to 'Documentation/git-merge.txt')
0 files changed, 0 insertions, 0 deletions