summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDerrick Stolee <dstolee@microsoft.com>2020-02-21 21:47:27 (GMT)
committerJunio C Hamano <gitster@pobox.com>2020-02-22 17:23:08 (GMT)
commitd0badf87978dceef4567bb032a74ea1f1a42632c (patch)
treeec967f0e2337d377f2d90d21fed760041497f691
parentd0654dc308b0ba76dd8ed7bbb33c8d8f7aacd783 (diff)
downloadgit-d0badf87978dceef4567bb032a74ea1f1a42632c.zip
git-d0badf87978dceef4567bb032a74ea1f1a42632c.tar.gz
git-d0badf87978dceef4567bb032a74ea1f1a42632c.tar.bz2
partial-clone: demonstrate bugs in partial fetch
While testing partial clone, I noticed some odd behavior. I was testing a way of running 'git init', followed by manually configuring the remote for partial clone, and then running 'git fetch'. Astonishingly, I saw the 'git fetch' process start asking the server for multiple rounds of pack-file downloads! When tweaking the situation a little more, I discovered that I could cause the remote to hang up with an error. Add two tests that demonstrate these two issues. In the first test, we find that when fetching with blob filters from a repository that previously did not have any tags, the 'git fetch --tags origin' command fails because the server sends "multiple filter-specs cannot be combined". This only happens when using protocol v2. In the second test, we see that a 'git fetch origin' request with several ref updates results in multiple pack-file downloads. This must be due to Git trying to fault-in the objects pointed by the refs. What makes this matter particularly nasty is that this goes through the do_oid_object_info_extended() method, so there are no "haves" in the negotiation. This leads the remote to send every reachable commit and tree from each new ref, providing a quadratic amount of data transfer! This test is fixed if we revert 6462d5eb9a (fetch: remove fetch_if_missing=0, 2019-11-05), but that revert causes other test failures. The real fix will need more care. The tests are ordered in this way because if I swap the test order the tag test will succeed instead of fail. I believe this is because somehow we need the srv.bare repo to not have any tags when we clone, but then have tags in our next fetch. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
-rwxr-xr-xt/t5616-partial-clone.sh31
1 files changed, 31 insertions, 0 deletions
diff --git a/t/t5616-partial-clone.sh b/t/t5616-partial-clone.sh
index fea56cd..022f101 100755
--- a/t/t5616-partial-clone.sh
+++ b/t/t5616-partial-clone.sh
@@ -374,6 +374,37 @@ test_expect_success 'fetch lazy-fetches only to resolve deltas, protocol v2' '
grep "want $(cat hash)" trace
'
+# The following two tests must be in this order, or else
+# the first will not fail. It is important that the srv.bare
+# repository did not have tags during clone, but has tags
+# in the fetch.
+
+test_expect_failure 'verify fetch succeeds when asking for new tags' '
+ git clone --filter=blob:none "file://$(pwd)/srv.bare" tag-test &&
+ for i in I J K
+ do
+ test_commit -C src $i &&
+ git -C src branch $i || return 1
+ done &&
+ git -C srv.bare fetch --tags origin +refs/heads/*:refs/heads/* &&
+ git -C tag-test -c protocol.version=2 fetch --tags origin
+'
+
+test_expect_failure 'verify fetch downloads only one pack when updating refs' '
+ git clone --filter=blob:none "file://$(pwd)/srv.bare" pack-test &&
+ ls pack-test/.git/objects/pack/*pack >pack-list &&
+ test_line_count = 2 pack-list &&
+ for i in A B C
+ do
+ test_commit -C src $i &&
+ git -C src branch $i || return 1
+ done &&
+ git -C srv.bare fetch origin +refs/heads/*:refs/heads/* &&
+ git -C pack-test fetch origin &&
+ ls pack-test/.git/objects/pack/*pack >pack-list &&
+ test_line_count = 3 pack-list
+'
+
. "$TEST_DIRECTORY"/lib-httpd.sh
start_httpd