git-commit-vandalism/t/t5702-protocol-v2.sh

891 lines
28 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='test git wire-protocol version 2'
TEST_NO_CREATE_REPO=1
. ./test-lib.sh
# Test protocol v2 with 'git://' transport
#
. "$TEST_DIRECTORY"/lib-git-daemon.sh
start_git_daemon --export-all --enable=receive-pack
daemon_parent=$GIT_DAEMON_DOCUMENT_ROOT_PATH/parent
test_expect_success 'create repo to be served by git-daemon' '
test_oid_init &&
git init "$daemon_parent" &&
test_commit -C "$daemon_parent" one
'
test_expect_success 'list refs with git:// using protocol v2' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" git -c protocol.version=2 \
ls-remote --symref "$GIT_DAEMON_URL/parent" >actual &&
# Client requested to use protocol v2
grep "git> .*\\\0\\\0version=2\\\0$" log &&
# Server responded using protocol v2
grep "git< version 2" log &&
git ls-remote --symref "$GIT_DAEMON_URL/parent" >expect &&
test_cmp expect actual
'
test_expect_success 'ref advertisement is filtered with ls-remote using protocol v2' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" git -c protocol.version=2 \
ls-remote "$GIT_DAEMON_URL/parent" master >actual &&
cat >expect <<-EOF &&
$(git -C "$daemon_parent" rev-parse refs/heads/master)$(printf "\t")refs/heads/master
EOF
test_cmp expect actual
'
test_expect_success 'clone with git:// using protocol v2' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" git -c protocol.version=2 \
clone "$GIT_DAEMON_URL/parent" daemon_child &&
git -C daemon_child log -1 --format=%s >actual &&
git -C "$daemon_parent" log -1 --format=%s >expect &&
test_cmp expect actual &&
# Client requested to use protocol v2
grep "clone> .*\\\0\\\0version=2\\\0$" log &&
# Server responded using protocol v2
grep "clone< version 2" log
'
test_expect_success 'fetch with git:// using protocol v2' '
test_when_finished "rm -f log" &&
test_commit -C "$daemon_parent" two &&
GIT_TRACE_PACKET="$(pwd)/log" git -C daemon_child -c protocol.version=2 \
fetch &&
git -C daemon_child log -1 --format=%s origin/master >actual &&
git -C "$daemon_parent" log -1 --format=%s >expect &&
test_cmp expect actual &&
# Client requested to use protocol v2
grep "fetch> .*\\\0\\\0version=2\\\0$" log &&
# Server responded using protocol v2
grep "fetch< version 2" log
'
test_expect_success 'fetch by hash without tag following with protocol v2 does not list refs' '
test_when_finished "rm -f log" &&
test_commit -C "$daemon_parent" two_a &&
git -C "$daemon_parent" rev-parse two_a >two_a_hash &&
GIT_TRACE_PACKET="$(pwd)/log" git -C daemon_child -c protocol.version=2 \
fetch --no-tags origin $(cat two_a_hash) &&
grep "fetch< version 2" log &&
! grep "fetch> command=ls-refs" log
'
test_expect_success 'pull with git:// using protocol v2' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" git -C daemon_child -c protocol.version=2 \
pull &&
git -C daemon_child log -1 --format=%s >actual &&
git -C "$daemon_parent" log -1 --format=%s >expect &&
test_cmp expect actual &&
# Client requested to use protocol v2
grep "fetch> .*\\\0\\\0version=2\\\0$" log &&
# Server responded using protocol v2
grep "fetch< version 2" log
'
test_expect_success 'push with git:// and a config of v2 does not request v2' '
test_when_finished "rm -f log" &&
# Till v2 for push is designed, make sure that if a client has
# protocol.version configured to use v2, that the client instead falls
# back and uses v0.
test_commit -C daemon_child three &&
# Push to another branch, as the target repository has the
# master branch checked out and we cannot push into it.
GIT_TRACE_PACKET="$(pwd)/log" git -C daemon_child -c protocol.version=2 \
push origin HEAD:client_branch &&
git -C daemon_child log -1 --format=%s >actual &&
git -C "$daemon_parent" log -1 --format=%s client_branch >expect &&
test_cmp expect actual &&
# Client requested to use protocol v2
! grep "push> .*\\\0\\\0version=2\\\0$" log &&
# Server responded using protocol v2
! grep "push< version 2" log
'
stop_git_daemon
# Test protocol v2 with 'file://' transport
#
test_expect_success 'create repo to be served by file:// transport' '
git init file_parent &&
test_commit -C file_parent one
'
test_expect_success 'list refs with file:// using protocol v2' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" git -c protocol.version=2 \
ls-remote --symref "file://$(pwd)/file_parent" >actual &&
# Server responded using protocol v2
grep "git< version 2" log &&
git ls-remote --symref "file://$(pwd)/file_parent" >expect &&
test_cmp expect actual
'
test_expect_success 'ref advertisement is filtered with ls-remote using protocol v2' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" git -c protocol.version=2 \
ls-remote "file://$(pwd)/file_parent" master >actual &&
cat >expect <<-EOF &&
$(git -C file_parent rev-parse refs/heads/master)$(printf "\t")refs/heads/master
EOF
test_cmp expect actual
'
test_expect_success 'server-options are sent when using ls-remote' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" git -c protocol.version=2 \
ls-remote -o hello -o world "file://$(pwd)/file_parent" master >actual &&
cat >expect <<-EOF &&
$(git -C file_parent rev-parse refs/heads/master)$(printf "\t")refs/heads/master
EOF
test_cmp expect actual &&
grep "server-option=hello" log &&
grep "server-option=world" log
'
test_expect_success 'warn if using server-option with ls-remote with legacy protocol' '
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 git -c protocol.version=0 \
ls-remote -o hello -o world "file://$(pwd)/file_parent" master 2>err &&
test_i18ngrep "see protocol.version in" err &&
test_i18ngrep "server options require protocol version 2 or later" err
'
test_expect_success 'clone with file:// using protocol v2' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" git -c protocol.version=2 \
clone "file://$(pwd)/file_parent" file_child &&
git -C file_child log -1 --format=%s >actual &&
git -C file_parent log -1 --format=%s >expect &&
test_cmp expect actual &&
# Server responded using protocol v2
grep "clone< version 2" log &&
# Client sent ref-prefixes to filter the ref-advertisement
grep "ref-prefix HEAD" log &&
grep "ref-prefix refs/heads/" log &&
grep "ref-prefix refs/tags/" log
'
test_expect_success 'fetch with file:// using protocol v2' '
test_when_finished "rm -f log" &&
test_commit -C file_parent two &&
GIT_TRACE_PACKET="$(pwd)/log" git -C file_child -c protocol.version=2 \
fetch origin &&
git -C file_child log -1 --format=%s origin/master >actual &&
git -C file_parent log -1 --format=%s >expect &&
test_cmp expect actual &&
# Server responded using protocol v2
grep "fetch< version 2" log
'
test_expect_success 'ref advertisement is filtered during fetch using protocol v2' '
test_when_finished "rm -f log" &&
test_commit -C file_parent three &&
git -C file_parent branch unwanted-branch three &&
GIT_TRACE_PACKET="$(pwd)/log" git -C file_child -c protocol.version=2 \
fetch origin master &&
git -C file_child log -1 --format=%s origin/master >actual &&
git -C file_parent log -1 --format=%s >expect &&
test_cmp expect actual &&
grep "refs/heads/master" log &&
! grep "refs/heads/unwanted-branch" log
'
test_expect_success 'server-options are sent when fetching' '
test_when_finished "rm -f log" &&
test_commit -C file_parent four &&
GIT_TRACE_PACKET="$(pwd)/log" git -C file_child -c protocol.version=2 \
fetch -o hello -o world origin master &&
git -C file_child log -1 --format=%s origin/master >actual &&
git -C file_parent log -1 --format=%s >expect &&
test_cmp expect actual &&
grep "server-option=hello" log &&
grep "server-option=world" log
'
test_expect_success 'warn if using server-option with fetch with legacy protocol' '
test_when_finished "rm -rf temp_child" &&
git init temp_child &&
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 git -C temp_child -c protocol.version=0 \
fetch -o hello -o world "file://$(pwd)/file_parent" master 2>err &&
test_i18ngrep "see protocol.version in" err &&
test_i18ngrep "server options require protocol version 2 or later" err
'
test_expect_success 'server-options are sent when cloning' '
test_when_finished "rm -rf log myclone" &&
GIT_TRACE_PACKET="$(pwd)/log" git -c protocol.version=2 \
clone --server-option=hello --server-option=world \
"file://$(pwd)/file_parent" myclone &&
grep "server-option=hello" log &&
grep "server-option=world" log
'
test_expect_success 'warn if using server-option with clone with legacy protocol' '
test_when_finished "rm -rf myclone" &&
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 git -c protocol.version=0 \
clone --server-option=hello --server-option=world \
"file://$(pwd)/file_parent" myclone 2>err &&
test_i18ngrep "see protocol.version in" err &&
test_i18ngrep "server options require protocol version 2 or later" err
'
test_expect_success 'upload-pack respects config using protocol v2' '
git init server &&
write_script server/.git/hook <<-\EOF &&
touch hookout
"$@"
EOF
test_commit -C server one &&
test_config_global uploadpack.packobjectshook ./hook &&
test_path_is_missing server/.git/hookout &&
git -c protocol.version=2 clone "file://$(pwd)/server" client &&
test_path_is_file server/.git/hookout
'
test_expect_success 'setup filter tests' '
rm -rf server client &&
git init server &&
# 1 commit to create a file, and 1 commit to modify it
test_commit -C server message1 a.txt &&
test_commit -C server message2 a.txt &&
git -C server config protocol.version 2 &&
git -C server config uploadpack.allowfilter 1 &&
git -C server config uploadpack.allowanysha1inwant 1 &&
git -C server config protocol.version 2
'
test_expect_success 'partial clone' '
GIT_TRACE_PACKET="$(pwd)/trace" git -c protocol.version=2 \
clone --filter=blob:none "file://$(pwd)/server" client &&
grep "version 2" trace &&
# Ensure that the old version of the file is missing
git -C client rev-list --quiet --objects --missing=print master \
>observed.oids &&
grep "$(git -C server rev-parse message1:a.txt)" observed.oids &&
# Ensure that client passes fsck
git -C client fsck
'
test_expect_success 'dynamically fetch missing object' '
rm "$(pwd)/trace" &&
GIT_TRACE_PACKET="$(pwd)/trace" git -C client -c protocol.version=2 \
cat-file -p $(git -C server rev-parse message1:a.txt) &&
grep "version 2" trace
'
test_expect_success 'when dynamically fetching missing object, do not list refs' '
! grep "git> command=ls-refs" trace
'
test_expect_success 'partial fetch' '
rm -rf client "$(pwd)/trace" &&
git init client &&
SERVER="file://$(pwd)/server" &&
GIT_TRACE_PACKET="$(pwd)/trace" git -C client -c protocol.version=2 \
fetch --filter=blob:none "$SERVER" master:refs/heads/other &&
grep "version 2" trace &&
# Ensure that the old version of the file is missing
git -C client rev-list --quiet --objects --missing=print other \
>observed.oids &&
grep "$(git -C server rev-parse message1:a.txt)" observed.oids &&
# Ensure that client passes fsck
git -C client fsck
'
test_expect_success 'do not advertise filter if not configured to do so' '
SERVER="file://$(pwd)/server" &&
rm "$(pwd)/trace" &&
git -C server config uploadpack.allowfilter 1 &&
GIT_TRACE_PACKET="$(pwd)/trace" git -c protocol.version=2 \
ls-remote "$SERVER" &&
grep "fetch=.*filter" trace &&
rm "$(pwd)/trace" &&
git -C server config uploadpack.allowfilter 0 &&
GIT_TRACE_PACKET="$(pwd)/trace" git -c protocol.version=2 \
ls-remote "$SERVER" &&
grep "fetch=" trace >fetch_capabilities &&
! grep filter fetch_capabilities
'
test_expect_success 'partial clone warns if filter is not advertised' '
rm -rf client &&
git -C server config uploadpack.allowfilter 0 &&
git -c protocol.version=2 \
clone --filter=blob:none "file://$(pwd)/server" client 2>err &&
test_i18ngrep "filtering not recognized by server, ignoring" err
'
test_expect_success 'even with handcrafted request, filter does not work if not advertised' '
git -C server config uploadpack.allowfilter 0 &&
# Custom request that tries to filter even though it is not advertised.
test-tool pkt-line pack >in <<-EOF &&
command=fetch
object-format=$(test_oid algo)
0001
want $(git -C server rev-parse master)
filter blob:none
0000
EOF
test_must_fail test-tool -C server serve-v2 --stateless-rpc \
<in >/dev/null 2>err &&
grep "unexpected line: .filter blob:none." err &&
# Exercise to ensure that if advertised, filter works
git -C server config uploadpack.allowfilter 1 &&
test-tool -C server serve-v2 --stateless-rpc <in >/dev/null
'
test_expect_success 'default refspec is used to filter ref when fetchcing' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" git -C file_child -c protocol.version=2 \
fetch origin &&
git -C file_child log -1 --format=%s three >actual &&
git -C file_parent log -1 --format=%s three >expect &&
test_cmp expect actual &&
grep "ref-prefix refs/heads/" log &&
grep "ref-prefix refs/tags/" log
'
test_expect_success 'fetch supports various ways of have lines' '
rm -rf server client trace &&
git init server &&
test_commit -C server dwim &&
TREE=$(git -C server rev-parse HEAD^{tree}) &&
git -C server tag exact \
$(git -C server commit-tree -m a "$TREE") &&
git -C server tag dwim-unwanted \
$(git -C server commit-tree -m b "$TREE") &&
git -C server tag exact-unwanted \
$(git -C server commit-tree -m c "$TREE") &&
git -C server tag prefix1 \
$(git -C server commit-tree -m d "$TREE") &&
git -C server tag prefix2 \
$(git -C server commit-tree -m e "$TREE") &&
git -C server tag fetch-by-sha1 \
$(git -C server commit-tree -m f "$TREE") &&
git -C server tag completely-unrelated \
$(git -C server commit-tree -m g "$TREE") &&
git init client &&
GIT_TRACE_PACKET="$(pwd)/trace" git -C client -c protocol.version=2 \
fetch "file://$(pwd)/server" \
dwim \
refs/tags/exact \
refs/tags/prefix*:refs/tags/prefix* \
"$(git -C server rev-parse fetch-by-sha1)" &&
# Ensure that the appropriate prefixes are sent (using a sample)
grep "fetch> ref-prefix dwim" trace &&
grep "fetch> ref-prefix refs/heads/dwim" trace &&
grep "fetch> ref-prefix refs/tags/prefix" trace &&
# Ensure that the correct objects are returned
git -C client cat-file -e $(git -C server rev-parse dwim) &&
git -C client cat-file -e $(git -C server rev-parse exact) &&
git -C client cat-file -e $(git -C server rev-parse prefix1) &&
git -C client cat-file -e $(git -C server rev-parse prefix2) &&
git -C client cat-file -e $(git -C server rev-parse fetch-by-sha1) &&
test_must_fail git -C client cat-file -e \
$(git -C server rev-parse dwim-unwanted) &&
test_must_fail git -C client cat-file -e \
$(git -C server rev-parse exact-unwanted) &&
test_must_fail git -C client cat-file -e \
$(git -C server rev-parse completely-unrelated)
'
test_expect_success 'fetch supports include-tag and tag following' '
rm -rf server client trace &&
git init server &&
test_commit -C server to_fetch &&
git -C server tag -a annotated_tag -m message &&
git init client &&
GIT_TRACE_PACKET="$(pwd)/trace" git -C client -c protocol.version=2 \
fetch "$(pwd)/server" to_fetch:to_fetch &&
grep "fetch> ref-prefix to_fetch" trace &&
grep "fetch> ref-prefix refs/tags/" trace &&
grep "fetch> include-tag" trace &&
git -C client cat-file -e $(git -C client rev-parse annotated_tag)
'
upload-pack: clear flags before each v2 request Suppose a server has the following commit graph: A B \ / O We create a client by cloning A from the server with depth 1, and add many commits to it (so that future fetches span multiple requests due to lengthy negotiation). If it then fetches B using protocol v2, the fetch spanning multiple requests, the resulting packfile does not contain O even though the client did report that A is shallow. This is because upload_pack_v2() can be called multiple times while processing the same session. During the 2nd and all subsequent invocations, some object flags remain from the previous invocations. In particular, CLIENT_SHALLOW remains, preventing process_shallow() from adding client-reported shallows to the "shallows" array, and hence pack-objects not knowing about these client-reported shallows. Therefore, teach upload_pack_v2() to clear object flags at the start of each invocation. This has some other results: - THEY_HAVE gates addition of objects to have_obj in process_haves(). Previously in upload_pack_v2(), have_obj needed to be static because once an object is added to have_obj, it is never readded and thus we needed to retain the contents of have_obj between invocations. Now that flags are cleared, this is no longer necessary. This patch does not change the behavior of ok_to_give_up() (THEY_HAVE is still set on each "have") and got_oid() (used only in non-v2)); THEY_HAVE is not used in any other function. - WANTED gates addition of objects to want_obj in parse_want() and parse_want_ref(). It is also used in receive_needs(), but that is only used in non-v2. For the same reasons as THEY_HAVE, want_obj no longer needs to be static in upload_pack_v2(). - CLIENT_SHALLOW is changed as discussed above. Clearing of the other 5 flags does not affect functionality in v2. (Note that in non-v2, upload_pack() is only called once per process, so each invocation starts with blank flags anyway.) - OUR_REF is only used in non-v2. - COMMON_KNOWN is only used as a scratch flag in ok_to_give_up(). - SHALLOW is passed to invocations in deepen() and deepen_by_rev_list(), but upload-pack doesn't use it. - NOT_SHALLOW is used by send_shallow() and send_unshallow(), but invocations of those functions are always preceded by code that sets NOT_SHALLOW on the appropriate objects. - HIDDEN_REF is only used in non-v2. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-18 22:43:29 +02:00
test_expect_success 'upload-pack respects client shallows' '
rm -rf server client trace &&
git init server &&
test_commit -C server base &&
test_commit -C server client_has &&
git clone --depth=1 "file://$(pwd)/server" client &&
# Add extra commits to the client so that the whole fetch takes more
# than 1 request (due to negotiation)
test_commit_bulk -C client --id=c 32 &&
upload-pack: clear flags before each v2 request Suppose a server has the following commit graph: A B \ / O We create a client by cloning A from the server with depth 1, and add many commits to it (so that future fetches span multiple requests due to lengthy negotiation). If it then fetches B using protocol v2, the fetch spanning multiple requests, the resulting packfile does not contain O even though the client did report that A is shallow. This is because upload_pack_v2() can be called multiple times while processing the same session. During the 2nd and all subsequent invocations, some object flags remain from the previous invocations. In particular, CLIENT_SHALLOW remains, preventing process_shallow() from adding client-reported shallows to the "shallows" array, and hence pack-objects not knowing about these client-reported shallows. Therefore, teach upload_pack_v2() to clear object flags at the start of each invocation. This has some other results: - THEY_HAVE gates addition of objects to have_obj in process_haves(). Previously in upload_pack_v2(), have_obj needed to be static because once an object is added to have_obj, it is never readded and thus we needed to retain the contents of have_obj between invocations. Now that flags are cleared, this is no longer necessary. This patch does not change the behavior of ok_to_give_up() (THEY_HAVE is still set on each "have") and got_oid() (used only in non-v2)); THEY_HAVE is not used in any other function. - WANTED gates addition of objects to want_obj in parse_want() and parse_want_ref(). It is also used in receive_needs(), but that is only used in non-v2. For the same reasons as THEY_HAVE, want_obj no longer needs to be static in upload_pack_v2(). - CLIENT_SHALLOW is changed as discussed above. Clearing of the other 5 flags does not affect functionality in v2. (Note that in non-v2, upload_pack() is only called once per process, so each invocation starts with blank flags anyway.) - OUR_REF is only used in non-v2. - COMMON_KNOWN is only used as a scratch flag in ok_to_give_up(). - SHALLOW is passed to invocations in deepen() and deepen_by_rev_list(), but upload-pack doesn't use it. - NOT_SHALLOW is used by send_shallow() and send_unshallow(), but invocations of those functions are always preceded by code that sets NOT_SHALLOW on the appropriate objects. - HIDDEN_REF is only used in non-v2. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-18 22:43:29 +02:00
git -C server checkout -b newbranch base &&
test_commit -C server client_wants &&
GIT_TRACE_PACKET="$(pwd)/trace" git -C client -c protocol.version=2 \
fetch origin newbranch &&
# Ensure that protocol v2 is used
grep "fetch< version 2" trace
'
test_expect_success 'ensure that multiple fetches in same process from a shallow repo works' '
rm -rf server client trace &&
test_create_repo server &&
test_commit -C server one &&
test_commit -C server two &&
test_commit -C server three &&
git clone --shallow-exclude two "file://$(pwd)/server" client &&
git -C server tag -a -m "an annotated tag" twotag two &&
# Triggers tag following (thus, 2 fetches in one process)
GIT_TRACE_PACKET="$(pwd)/trace" git -C client -c protocol.version=2 \
fetch --shallow-exclude one origin &&
# Ensure that protocol v2 is used
grep "fetch< version 2" trace
upload-pack: clear flags before each v2 request Suppose a server has the following commit graph: A B \ / O We create a client by cloning A from the server with depth 1, and add many commits to it (so that future fetches span multiple requests due to lengthy negotiation). If it then fetches B using protocol v2, the fetch spanning multiple requests, the resulting packfile does not contain O even though the client did report that A is shallow. This is because upload_pack_v2() can be called multiple times while processing the same session. During the 2nd and all subsequent invocations, some object flags remain from the previous invocations. In particular, CLIENT_SHALLOW remains, preventing process_shallow() from adding client-reported shallows to the "shallows" array, and hence pack-objects not knowing about these client-reported shallows. Therefore, teach upload_pack_v2() to clear object flags at the start of each invocation. This has some other results: - THEY_HAVE gates addition of objects to have_obj in process_haves(). Previously in upload_pack_v2(), have_obj needed to be static because once an object is added to have_obj, it is never readded and thus we needed to retain the contents of have_obj between invocations. Now that flags are cleared, this is no longer necessary. This patch does not change the behavior of ok_to_give_up() (THEY_HAVE is still set on each "have") and got_oid() (used only in non-v2)); THEY_HAVE is not used in any other function. - WANTED gates addition of objects to want_obj in parse_want() and parse_want_ref(). It is also used in receive_needs(), but that is only used in non-v2. For the same reasons as THEY_HAVE, want_obj no longer needs to be static in upload_pack_v2(). - CLIENT_SHALLOW is changed as discussed above. Clearing of the other 5 flags does not affect functionality in v2. (Note that in non-v2, upload_pack() is only called once per process, so each invocation starts with blank flags anyway.) - OUR_REF is only used in non-v2. - COMMON_KNOWN is only used as a scratch flag in ok_to_give_up(). - SHALLOW is passed to invocations in deepen() and deepen_by_rev_list(), but upload-pack doesn't use it. - NOT_SHALLOW is used by send_shallow() and send_unshallow(), but invocations of those functions are always preceded by code that sets NOT_SHALLOW on the appropriate objects. - HIDDEN_REF is only used in non-v2. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-18 22:43:29 +02:00
'
test_expect_success 'deepen-relative' '
rm -rf server client trace &&
test_create_repo server &&
test_commit -C server one &&
test_commit -C server two &&
test_commit -C server three &&
git clone --depth 1 "file://$(pwd)/server" client &&
test_commit -C server four &&
# Sanity check that only "three" is downloaded
git -C client log --pretty=tformat:%s master >actual &&
echo three >expected &&
test_cmp expected actual &&
GIT_TRACE_PACKET="$(pwd)/trace" git -C client -c protocol.version=2 \
fetch --deepen=1 origin &&
# Ensure that protocol v2 is used
grep "fetch< version 2" trace &&
git -C client log --pretty=tformat:%s origin/master >actual &&
cat >expected <<-\EOF &&
four
three
two
EOF
test_cmp expected actual
'
# Test protocol v2 with 'http://' transport
#
. "$TEST_DIRECTORY"/lib-httpd.sh
start_httpd
test_expect_success 'create repo to be served by http:// transport' '
git init "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" &&
git -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" config http.receivepack true &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" one
'
test_expect_success 'clone with http:// using protocol v2' '
test_when_finished "rm -f log" &&
GIT_TRACE_PACKET="$(pwd)/log" GIT_TRACE_CURL="$(pwd)/log" git -c protocol.version=2 \
clone "$HTTPD_URL/smart/http_parent" http_child &&
git -C http_child log -1 --format=%s >actual &&
git -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" log -1 --format=%s >expect &&
test_cmp expect actual &&
# Client requested to use protocol v2
grep "Git-Protocol: version=2" log &&
# Server responded using protocol v2
grep "git< version 2" log &&
# Verify that the chunked encoding sending codepath is NOT exercised
! grep "Send header: Transfer-Encoding: chunked" log
'
test_expect_success 'clone repository with http:// using protocol v2 with incomplete pktline length' '
test_when_finished "rm -f log" &&
git init "$HTTPD_DOCUMENT_ROOT_PATH/incomplete_length" &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/incomplete_length" file &&
test_must_fail env GIT_TRACE_PACKET="$(pwd)/log" GIT_TRACE_CURL="$(pwd)/log" git -c protocol.version=2 \
clone "$HTTPD_URL/smart/incomplete_length" incomplete_length_child 2>err &&
# Client requested to use protocol v2
grep "Git-Protocol: version=2" log &&
# Server responded using protocol v2
grep "git< version 2" log &&
# Client reported appropriate failure
test_i18ngrep "bytes of length header were received" err
'
test_expect_success 'clone repository with http:// using protocol v2 with incomplete pktline body' '
test_when_finished "rm -f log" &&
git init "$HTTPD_DOCUMENT_ROOT_PATH/incomplete_body" &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/incomplete_body" file &&
test_must_fail env GIT_TRACE_PACKET="$(pwd)/log" GIT_TRACE_CURL="$(pwd)/log" git -c protocol.version=2 \
clone "$HTTPD_URL/smart/incomplete_body" incomplete_body_child 2>err &&
# Client requested to use protocol v2
grep "Git-Protocol: version=2" log &&
# Server responded using protocol v2
grep "git< version 2" log &&
# Client reported appropriate failure
test_i18ngrep "bytes of body are still expected" err
'
stateless-connect: send response end packet Currently, remote-curl acts as a proxy and blindly forwards packets between an HTTP server and fetch-pack. In the case of a stateless RPC connection where the connection is terminated before the transaction is complete, remote-curl will blindly forward the packets before waiting on more input from fetch-pack. Meanwhile, fetch-pack will read the transaction and continue reading, expecting more input to continue the transaction. This results in a deadlock between the two processes. This can be seen in the following command which does not terminate: $ git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012 Cloning into 'git'... whereas the v1 version does terminate as expected: $ git -c protocol.version=1 clone https://github.com/git/git.git --shallow-since=20151012 Cloning into 'git'... fatal: the remote end hung up unexpectedly Instead of blindly forwarding packets, make remote-curl insert a response end packet after proxying the responses from the remote server when using stateless_connect(). On the RPC client side, ensure that each response ends as described. A separate control packet is chosen because we need to be able to differentiate between what the remote server sends and remote-curl's control packets. By ensuring in the remote-curl code that a server cannot send response end packets, we prevent a malicious server from being able to perform a denial of service attack in which they spoof a response end packet and cause the described deadlock to happen. Reported-by: Force Charlie <charlieio@outlook.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-19 12:54:00 +02:00
test_expect_success 'clone with http:// using protocol v2 and invalid parameters' '
test_when_finished "rm -f log" &&
test_must_fail env GIT_TRACE_PACKET="$(pwd)/log" GIT_TRACE_CURL="$(pwd)/log" \
git -c protocol.version=2 \
clone --shallow-since=20151012 "$HTTPD_URL/smart/http_parent" http_child_invalid &&
# Client requested to use protocol v2
grep "Git-Protocol: version=2" log &&
# Server responded using protocol v2
grep "git< version 2" log
'
test_expect_success 'clone big repository with http:// using protocol v2' '
test_when_finished "rm -f log" &&
git init "$HTTPD_DOCUMENT_ROOT_PATH/big" &&
# Ensure that the list of wants is greater than http.postbuffer below
for i in $(test_seq 1 1500)
do
# do not use here-doc, because it requires a process
# per loop iteration
echo "commit refs/heads/too-many-refs-$i" &&
echo "committer git <git@example.com> $i +0000" &&
echo "data 0" &&
echo "M 644 inline bla.txt" &&
echo "data 4" &&
echo "bla"
done | git -C "$HTTPD_DOCUMENT_ROOT_PATH/big" fast-import &&
GIT_TRACE_PACKET="$(pwd)/log" GIT_TRACE_CURL="$(pwd)/log" git \
-c protocol.version=2 -c http.postbuffer=65536 \
clone "$HTTPD_URL/smart/big" big_child &&
# Client requested to use protocol v2
grep "Git-Protocol: version=2" log &&
# Server responded using protocol v2
grep "git< version 2" log &&
# Verify that the chunked encoding sending codepath is exercised
grep "Send header: Transfer-Encoding: chunked" log
'
test_expect_success 'fetch with http:// using protocol v2' '
test_when_finished "rm -f log" &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" two &&
GIT_TRACE_PACKET="$(pwd)/log" git -C http_child -c protocol.version=2 \
fetch &&
git -C http_child log -1 --format=%s origin/master >actual &&
git -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" log -1 --format=%s >expect &&
test_cmp expect actual &&
# Server responded using protocol v2
grep "git< version 2" log
'
test_expect_success 'fetch with http:// by hash without tag following with protocol v2 does not list refs' '
test_when_finished "rm -f log" &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" two_a &&
git -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" rev-parse two_a >two_a_hash &&
GIT_TRACE_PACKET="$(pwd)/log" git -C http_child -c protocol.version=2 \
fetch --no-tags origin $(cat two_a_hash) &&
grep "fetch< version 2" log &&
! grep "fetch> command=ls-refs" log
'
test_expect_success 'fetch from namespaced repo respects namespaces' '
test_when_finished "rm -f log" &&
git init "$HTTPD_DOCUMENT_ROOT_PATH/nsrepo" &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/nsrepo" one &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/nsrepo" two &&
git -C "$HTTPD_DOCUMENT_ROOT_PATH/nsrepo" \
update-ref refs/namespaces/ns/refs/heads/master one &&
GIT_TRACE_PACKET="$(pwd)/log" git -C http_child -c protocol.version=2 \
fetch "$HTTPD_URL/smart_namespace/nsrepo" \
refs/heads/master:refs/heads/theirs &&
# Server responded using protocol v2
grep "fetch< version 2" log &&
git -C "$HTTPD_DOCUMENT_ROOT_PATH/nsrepo" rev-parse one >expect &&
git -C http_child rev-parse theirs >actual &&
test_cmp expect actual
'
test_expect_success 'ls-remote with v2 http sends only one POST' '
test_when_finished "rm -f log" &&
git ls-remote "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" >expect &&
GIT_TRACE_CURL="$(pwd)/log" git -c protocol.version=2 \
ls-remote "$HTTPD_URL/smart/http_parent" >actual &&
test_cmp expect actual &&
grep "Send header: POST" log >posts &&
test_line_count = 1 posts
'
test_expect_success 'push with http:// and a config of v2 does not request v2' '
test_when_finished "rm -f log" &&
# Till v2 for push is designed, make sure that if a client has
# protocol.version configured to use v2, that the client instead falls
# back and uses v0.
test_commit -C http_child three &&
# Push to another branch, as the target repository has the
# master branch checked out and we cannot push into it.
GIT_TRACE_PACKET="$(pwd)/log" git -C http_child -c protocol.version=2 \
push origin HEAD:client_branch &&
git -C http_child log -1 --format=%s >actual &&
git -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" log -1 --format=%s client_branch >expect &&
test_cmp expect actual &&
# Client did not request to use protocol v2
! grep "Git-Protocol: version=2" log &&
# Server did not respond using protocol v2
! grep "git< version 2" log
'
fetch-pack: be more precise in parsing v2 response Each section in a protocol v2 response is followed by either a DELIM packet (indicating more sections to follow) or a FLUSH packet (indicating none to follow). But when parsing the "acknowledgments" section, do_fetch_pack_v2() is liberal in accepting both, but determines whether to continue reading or not based solely on the contents of the "acknowledgments" section, not on whether DELIM or FLUSH was read. There is no issue with a protocol-compliant server, but can result in confusing error messages when communicating with a server that serves unexpected additional sections. Consider a server that sends "new-section" after "acknowledgments": - client writes request - client reads the "acknowledgments" section which contains no "ready", then DELIM - since there was no "ready", client needs to continue negotiation, and writes request - client reads "new-section", and reports to the end user "expected 'acknowledgments', received 'new-section'" For the person debugging the involved Git implementation(s), the error message is confusing in that "new-section" was not received in response to the latest request, but to the first one. One solution is to always continue reading after DELIM, but in this case, we can do better. We know from the protocol that "ready" means at least the packfile section is coming (hence, DELIM) and that no "ready" means that no sections are to follow (hence, FLUSH). So teach process_acks() to enforce this. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-20 00:54:04 +02:00
test_expect_success 'when server sends "ready", expect DELIM' '
rm -rf "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" http_child &&
git init "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" one &&
git clone "$HTTPD_URL/smart/http_parent" http_child &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" two &&
# After "ready" in the acknowledgments section, pretend that a FLUSH
# (0000) was sent instead of a DELIM (0001).
t/lib-httpd: avoid using macOS' sed Among other differences relative to GNU sed, macOS' sed always ends its output with a trailing newline, even if the input did not have such a trailing newline. Surprisingly, this makes three httpd-based tests fail on macOS: t5616, t5702 and t5703. ("Surprisingly" because those tests have been around for some time, but apparently nobody runs them on macOS with a working Apache2 setup.) The reason is that we use `sed` in those tests to filter the response of the web server. Apart from the fact that we use GNU constructs (such as using a space after the `c` command instead of a backslash and a newline), we have another problem: macOS' sed LF-only newlines while webservers are supposed to use CR/LF ones. Even worse, t5616 uses `sed` to replace a binary part of the response with a new binary part (kind of hoping that the replaced binary part does not contain a 0x0a byte which would be interpreted as a newline). To that end, it calls on Perl to read the binary pack file and hex-encode it, then calls on `sed` to prefix every hex digit pair with a `\x` in order to construct the text that the `c` statement of the `sed` invocation is supposed to insert. So we call Perl and sed to construct a sed statement. The final nail in the coffin is that macOS' sed does not even interpret those `\x<hex>` constructs. Let's just replace all of that by Perl snippets. With Perl, at least, we do not have to deal with GNU vs macOS semantics, we do not have to worry about unwanted trailing newlines, and we do not have to spawn commands to construct arguments for other commands to be spawned (i.e. we can avoid a whole lot of shell scripting complexity). The upshot is that this fixes t5616, t5702 and t5703 on macOS with Apache2. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27 14:23:11 +01:00
printf "\$ready = 1 if /ready/; \$ready && s/0001/0000/" \
>"$HTTPD_ROOT_PATH/one-time-perl" &&
fetch-pack: be more precise in parsing v2 response Each section in a protocol v2 response is followed by either a DELIM packet (indicating more sections to follow) or a FLUSH packet (indicating none to follow). But when parsing the "acknowledgments" section, do_fetch_pack_v2() is liberal in accepting both, but determines whether to continue reading or not based solely on the contents of the "acknowledgments" section, not on whether DELIM or FLUSH was read. There is no issue with a protocol-compliant server, but can result in confusing error messages when communicating with a server that serves unexpected additional sections. Consider a server that sends "new-section" after "acknowledgments": - client writes request - client reads the "acknowledgments" section which contains no "ready", then DELIM - since there was no "ready", client needs to continue negotiation, and writes request - client reads "new-section", and reports to the end user "expected 'acknowledgments', received 'new-section'" For the person debugging the involved Git implementation(s), the error message is confusing in that "new-section" was not received in response to the latest request, but to the first one. One solution is to always continue reading after DELIM, but in this case, we can do better. We know from the protocol that "ready" means at least the packfile section is coming (hence, DELIM) and that no "ready" means that no sections are to follow (hence, FLUSH). So teach process_acks() to enforce this. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-20 00:54:04 +02:00
test_must_fail git -C http_child -c protocol.version=2 \
t/lib-httpd: avoid using macOS' sed Among other differences relative to GNU sed, macOS' sed always ends its output with a trailing newline, even if the input did not have such a trailing newline. Surprisingly, this makes three httpd-based tests fail on macOS: t5616, t5702 and t5703. ("Surprisingly" because those tests have been around for some time, but apparently nobody runs them on macOS with a working Apache2 setup.) The reason is that we use `sed` in those tests to filter the response of the web server. Apart from the fact that we use GNU constructs (such as using a space after the `c` command instead of a backslash and a newline), we have another problem: macOS' sed LF-only newlines while webservers are supposed to use CR/LF ones. Even worse, t5616 uses `sed` to replace a binary part of the response with a new binary part (kind of hoping that the replaced binary part does not contain a 0x0a byte which would be interpreted as a newline). To that end, it calls on Perl to read the binary pack file and hex-encode it, then calls on `sed` to prefix every hex digit pair with a `\x` in order to construct the text that the `c` statement of the `sed` invocation is supposed to insert. So we call Perl and sed to construct a sed statement. The final nail in the coffin is that macOS' sed does not even interpret those `\x<hex>` constructs. Let's just replace all of that by Perl snippets. With Perl, at least, we do not have to deal with GNU vs macOS semantics, we do not have to worry about unwanted trailing newlines, and we do not have to spawn commands to construct arguments for other commands to be spawned (i.e. we can avoid a whole lot of shell scripting complexity). The upshot is that this fixes t5616, t5702 and t5703 on macOS with Apache2. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27 14:23:11 +01:00
fetch "$HTTPD_URL/one_time_perl/http_parent" 2> err &&
fetch-pack: be more precise in parsing v2 response Each section in a protocol v2 response is followed by either a DELIM packet (indicating more sections to follow) or a FLUSH packet (indicating none to follow). But when parsing the "acknowledgments" section, do_fetch_pack_v2() is liberal in accepting both, but determines whether to continue reading or not based solely on the contents of the "acknowledgments" section, not on whether DELIM or FLUSH was read. There is no issue with a protocol-compliant server, but can result in confusing error messages when communicating with a server that serves unexpected additional sections. Consider a server that sends "new-section" after "acknowledgments": - client writes request - client reads the "acknowledgments" section which contains no "ready", then DELIM - since there was no "ready", client needs to continue negotiation, and writes request - client reads "new-section", and reports to the end user "expected 'acknowledgments', received 'new-section'" For the person debugging the involved Git implementation(s), the error message is confusing in that "new-section" was not received in response to the latest request, but to the first one. One solution is to always continue reading after DELIM, but in this case, we can do better. We know from the protocol that "ready" means at least the packfile section is coming (hence, DELIM) and that no "ready" means that no sections are to follow (hence, FLUSH). So teach process_acks() to enforce this. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-20 00:54:04 +02:00
test_i18ngrep "expected packfile to be sent after .ready." err
'
test_expect_success 'when server does not send "ready", expect FLUSH' '
rm -rf "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" http_child log &&
git init "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" one &&
git clone "$HTTPD_URL/smart/http_parent" http_child &&
test_commit -C "$HTTPD_DOCUMENT_ROOT_PATH/http_parent" two &&
# Create many commits to extend the negotiation phase across multiple
# requests, so that the server does not send "ready" in the first
# request.
test_commit_bulk -C http_child --id=c 32 &&
fetch-pack: be more precise in parsing v2 response Each section in a protocol v2 response is followed by either a DELIM packet (indicating more sections to follow) or a FLUSH packet (indicating none to follow). But when parsing the "acknowledgments" section, do_fetch_pack_v2() is liberal in accepting both, but determines whether to continue reading or not based solely on the contents of the "acknowledgments" section, not on whether DELIM or FLUSH was read. There is no issue with a protocol-compliant server, but can result in confusing error messages when communicating with a server that serves unexpected additional sections. Consider a server that sends "new-section" after "acknowledgments": - client writes request - client reads the "acknowledgments" section which contains no "ready", then DELIM - since there was no "ready", client needs to continue negotiation, and writes request - client reads "new-section", and reports to the end user "expected 'acknowledgments', received 'new-section'" For the person debugging the involved Git implementation(s), the error message is confusing in that "new-section" was not received in response to the latest request, but to the first one. One solution is to always continue reading after DELIM, but in this case, we can do better. We know from the protocol that "ready" means at least the packfile section is coming (hence, DELIM) and that no "ready" means that no sections are to follow (hence, FLUSH). So teach process_acks() to enforce this. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-20 00:54:04 +02:00
# After the acknowledgments section, pretend that a DELIM
# (0001) was sent instead of a FLUSH (0000).
t/lib-httpd: avoid using macOS' sed Among other differences relative to GNU sed, macOS' sed always ends its output with a trailing newline, even if the input did not have such a trailing newline. Surprisingly, this makes three httpd-based tests fail on macOS: t5616, t5702 and t5703. ("Surprisingly" because those tests have been around for some time, but apparently nobody runs them on macOS with a working Apache2 setup.) The reason is that we use `sed` in those tests to filter the response of the web server. Apart from the fact that we use GNU constructs (such as using a space after the `c` command instead of a backslash and a newline), we have another problem: macOS' sed LF-only newlines while webservers are supposed to use CR/LF ones. Even worse, t5616 uses `sed` to replace a binary part of the response with a new binary part (kind of hoping that the replaced binary part does not contain a 0x0a byte which would be interpreted as a newline). To that end, it calls on Perl to read the binary pack file and hex-encode it, then calls on `sed` to prefix every hex digit pair with a `\x` in order to construct the text that the `c` statement of the `sed` invocation is supposed to insert. So we call Perl and sed to construct a sed statement. The final nail in the coffin is that macOS' sed does not even interpret those `\x<hex>` constructs. Let's just replace all of that by Perl snippets. With Perl, at least, we do not have to deal with GNU vs macOS semantics, we do not have to worry about unwanted trailing newlines, and we do not have to spawn commands to construct arguments for other commands to be spawned (i.e. we can avoid a whole lot of shell scripting complexity). The upshot is that this fixes t5616, t5702 and t5703 on macOS with Apache2. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27 14:23:11 +01:00
printf "\$ack = 1 if /acknowledgments/; \$ack && s/0000/0001/" \
>"$HTTPD_ROOT_PATH/one-time-perl" &&
fetch-pack: be more precise in parsing v2 response Each section in a protocol v2 response is followed by either a DELIM packet (indicating more sections to follow) or a FLUSH packet (indicating none to follow). But when parsing the "acknowledgments" section, do_fetch_pack_v2() is liberal in accepting both, but determines whether to continue reading or not based solely on the contents of the "acknowledgments" section, not on whether DELIM or FLUSH was read. There is no issue with a protocol-compliant server, but can result in confusing error messages when communicating with a server that serves unexpected additional sections. Consider a server that sends "new-section" after "acknowledgments": - client writes request - client reads the "acknowledgments" section which contains no "ready", then DELIM - since there was no "ready", client needs to continue negotiation, and writes request - client reads "new-section", and reports to the end user "expected 'acknowledgments', received 'new-section'" For the person debugging the involved Git implementation(s), the error message is confusing in that "new-section" was not received in response to the latest request, but to the first one. One solution is to always continue reading after DELIM, but in this case, we can do better. We know from the protocol that "ready" means at least the packfile section is coming (hence, DELIM) and that no "ready" means that no sections are to follow (hence, FLUSH). So teach process_acks() to enforce this. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-20 00:54:04 +02:00
test_must_fail env GIT_TRACE_PACKET="$(pwd)/log" git -C http_child \
-c protocol.version=2 \
t/lib-httpd: avoid using macOS' sed Among other differences relative to GNU sed, macOS' sed always ends its output with a trailing newline, even if the input did not have such a trailing newline. Surprisingly, this makes three httpd-based tests fail on macOS: t5616, t5702 and t5703. ("Surprisingly" because those tests have been around for some time, but apparently nobody runs them on macOS with a working Apache2 setup.) The reason is that we use `sed` in those tests to filter the response of the web server. Apart from the fact that we use GNU constructs (such as using a space after the `c` command instead of a backslash and a newline), we have another problem: macOS' sed LF-only newlines while webservers are supposed to use CR/LF ones. Even worse, t5616 uses `sed` to replace a binary part of the response with a new binary part (kind of hoping that the replaced binary part does not contain a 0x0a byte which would be interpreted as a newline). To that end, it calls on Perl to read the binary pack file and hex-encode it, then calls on `sed` to prefix every hex digit pair with a `\x` in order to construct the text that the `c` statement of the `sed` invocation is supposed to insert. So we call Perl and sed to construct a sed statement. The final nail in the coffin is that macOS' sed does not even interpret those `\x<hex>` constructs. Let's just replace all of that by Perl snippets. With Perl, at least, we do not have to deal with GNU vs macOS semantics, we do not have to worry about unwanted trailing newlines, and we do not have to spawn commands to construct arguments for other commands to be spawned (i.e. we can avoid a whole lot of shell scripting complexity). The upshot is that this fixes t5616, t5702 and t5703 on macOS with Apache2. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27 14:23:11 +01:00
fetch "$HTTPD_URL/one_time_perl/http_parent" 2> err &&
grep "fetch< .*acknowledgments" log &&
! grep "fetch< .*ready" log &&
fetch-pack: be more precise in parsing v2 response Each section in a protocol v2 response is followed by either a DELIM packet (indicating more sections to follow) or a FLUSH packet (indicating none to follow). But when parsing the "acknowledgments" section, do_fetch_pack_v2() is liberal in accepting both, but determines whether to continue reading or not based solely on the contents of the "acknowledgments" section, not on whether DELIM or FLUSH was read. There is no issue with a protocol-compliant server, but can result in confusing error messages when communicating with a server that serves unexpected additional sections. Consider a server that sends "new-section" after "acknowledgments": - client writes request - client reads the "acknowledgments" section which contains no "ready", then DELIM - since there was no "ready", client needs to continue negotiation, and writes request - client reads "new-section", and reports to the end user "expected 'acknowledgments', received 'new-section'" For the person debugging the involved Git implementation(s), the error message is confusing in that "new-section" was not received in response to the latest request, but to the first one. One solution is to always continue reading after DELIM, but in this case, we can do better. We know from the protocol that "ready" means at least the packfile section is coming (hence, DELIM) and that no "ready" means that no sections are to follow (hence, FLUSH). So teach process_acks() to enforce this. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-20 00:54:04 +02:00
test_i18ngrep "expected no other sections to be sent after no .ready." err
'
configure_exclusion () {
git -C "$1" hash-object "$2" >objh &&
git -C "$1" pack-objects "$HTTPD_DOCUMENT_ROOT_PATH/mypack" <objh >packh &&
git -C "$1" config --add \
"uploadpack.blobpackfileuri" \
"$(cat objh) $(cat packh) $HTTPD_URL/dumb/mypack-$(cat packh).pack" &&
cat objh
}
test_expect_success 'part of packfile response provided as URI' '
P="$HTTPD_DOCUMENT_ROOT_PATH/http_parent" &&
rm -rf "$P" http_child log &&
git init "$P" &&
git -C "$P" config "uploadpack.allowsidebandall" "true" &&
echo my-blob >"$P/my-blob" &&
git -C "$P" add my-blob &&
echo other-blob >"$P/other-blob" &&
git -C "$P" add other-blob &&
git -C "$P" commit -m x &&
configure_exclusion "$P" my-blob >h &&
configure_exclusion "$P" other-blob >h2 &&
GIT_TRACE=1 GIT_TRACE_PACKET="$(pwd)/log" GIT_TEST_SIDEBAND_ALL=1 \
git -c protocol.version=2 \
-c fetch.uriprotocols=http,https \
clone "$HTTPD_URL/smart/http_parent" http_child &&
# Ensure that my-blob and other-blob are in separate packfiles.
for idx in http_child/.git/objects/pack/*.idx
do
git verify-pack --verbose $idx >out &&
{
grep "^[0-9a-f]\{16,\} " out || :
} >out.objectlist &&
if test_line_count = 1 out.objectlist
then
if grep $(cat h) out
then
>hfound
fi &&
if grep $(cat h2) out
then
>h2found
fi
fi
done &&
test -f hfound &&
test -f h2found &&
# Ensure that there are exactly 6 files (3 .pack and 3 .idx).
ls http_child/.git/objects/pack/* >filelist &&
test_line_count = 6 filelist
'
test_expect_success 'fetching with valid packfile URI but invalid hash fails' '
P="$HTTPD_DOCUMENT_ROOT_PATH/http_parent" &&
rm -rf "$P" http_child log &&
git init "$P" &&
git -C "$P" config "uploadpack.allowsidebandall" "true" &&
echo my-blob >"$P/my-blob" &&
git -C "$P" add my-blob &&
echo other-blob >"$P/other-blob" &&
git -C "$P" add other-blob &&
git -C "$P" commit -m x &&
configure_exclusion "$P" my-blob >h &&
# Configure a URL for other-blob. Just reuse the hash of the object as
# the hash of the packfile, since the hash does not matter for this
# test as long as it is not the hash of the pack, and it is of the
# expected length.
git -C "$P" hash-object other-blob >objh &&
git -C "$P" pack-objects "$HTTPD_DOCUMENT_ROOT_PATH/mypack" <objh >packh &&
git -C "$P" config --add \
"uploadpack.blobpackfileuri" \
"$(cat objh) $(cat objh) $HTTPD_URL/dumb/mypack-$(cat packh).pack" &&
test_must_fail env GIT_TEST_SIDEBAND_ALL=1 \
git -c protocol.version=2 \
-c fetch.uriprotocols=http,https \
clone "$HTTPD_URL/smart/http_parent" http_child 2>err &&
test_i18ngrep "pack downloaded from.*does not match expected hash" err
'
# DO NOT add non-httpd-specific tests here, because the last part of this
# test script is only executed when httpd is available and enabled.
test_done