git/t/t5516-fetch-push.sh

1772 строки
47 KiB
Bash
Исходник Обычный вид История

#!/bin/sh
test_description='Basic fetch/push functionality.
This test checks the following functionality:
* command-line syntax
* refspecs
* fast-forward detection, and overriding it
* configuration
* hooks
* --porcelain output format
* hiderefs
* reflogs
'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 02:44:19 +03:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
D=$(pwd)
mk_empty () {
repo_name="$1"
rm -fr "$repo_name" &&
mkdir "$repo_name" &&
(
cd "$repo_name" &&
git init &&
git config receive.denyCurrentBranch warn &&
mv .git/hooks .git/hooks-disabled
)
}
mk_test () {
repo_name="$1"
shift
mk_empty "$repo_name" &&
(
for ref in "$@"
do
git push "$repo_name" $the_first_commit:refs/$ref ||
exit
done &&
cd "$repo_name" &&
for ref in "$@"
do
echo "$the_first_commit" >expect &&
git show-ref -s --verify refs/$ref >actual &&
test_cmp expect actual ||
exit
done &&
git fsck --full
)
}
mk_test_with_hooks() {
repo_name=$1
mk_test "$@" &&
(
cd "$repo_name" &&
mkdir .git/hooks &&
cd .git/hooks &&
cat >pre-receive <<-'EOF' &&
#!/bin/sh
cat - >>pre-receive.actual
EOF
cat >update <<-'EOF' &&
#!/bin/sh
printf "%s %s %s\n" "$@" >>update.actual
EOF
cat >post-receive <<-'EOF' &&
#!/bin/sh
cat - >>post-receive.actual
EOF
cat >post-update <<-'EOF' &&
#!/bin/sh
for ref in "$@"
do
printf "%s\n" "$ref" >>post-update.actual
done
EOF
chmod +x pre-receive update post-receive post-update
)
}
mk_child() {
rm -rf "$2" &&
git clone "$1" "$2"
}
check_push_result () {
test $# -ge 3 ||
tests: send "bug in the test script" errors to the script's stderr Some of the functions in our test library check that they were invoked properly with conditions like this: test "$#" = 2 || error "bug in the test script: not 2 parameters to test-expect-success" If this particular condition is triggered, then 'error' will abort the whole test script with a bold red error message [1] right away. However, under certain circumstances the test script will be aborted completely silently, namely if: - a similar condition in a test helper function like 'test_line_count' is triggered, - which is invoked from the test script's "main" shell [2], - and the test script is run manually (i.e. './t1234-foo.sh' as opposed to 'make t1234-foo.sh' or 'make test') [3] - and without the '--verbose' option, because the error message is printed from within 'test_eval_', where standard output is redirected either to /dev/null or to a log file. The only indication that something is wrong is that not all tests in the script are executed and at the end of the test script's output there is no "# passed all N tests" message, which are subtle and can easily go unnoticed, as I had to experience myself. Send these "bug in the test script" error messages directly to the test scripts standard error and thus to the terminal, so those bugs will be much harder to overlook. Instead of updating all ~20 such 'error' calls with a redirection, let's add a BUG() function to 'test-lib.sh', wrapping an 'error' call with the proper redirection and also including the common prefix of those error messages, and convert all those call sites [4] to use this new BUG() function instead. [1] That particular error message from 'test_expect_success' is printed in color only when running with or without '--verbose'; with '--tee' or '--verbose-log' the error is printed without color, but it is printed to the terminal nonetheless. [2] If such a condition is triggered in a subshell of a test, then 'error' won't be able to abort the whole test script, but only the subshell, which in turn causes the test to fail in the usual way, indicating loudly and clearly that something is wrong. [3] Well, 'error' aborts the test script the same way when run manually or by 'make' or 'prove', but both 'make' and 'prove' pay attention to the test script's exit status, and even a silently aborted test script would then trigger those tools' usual noticable error messages. [4] Strictly speaking, not all those 'error' calls need that redirection to send their output to the terminal, see e.g. 'test_expect_success' in the opening example, but I think it's better to be consistent. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 16:13:26 +03:00
BUG "check_push_result requires at least 3 parameters"
repo_name="$1"
shift
(
cd "$repo_name" &&
echo "$1" >expect &&
shift &&
for ref in "$@"
do
git show-ref -s --verify refs/$ref >actual &&
test_cmp expect actual ||
exit
done &&
git fsck --full
)
}
test_expect_success setup '
>path1 &&
git add path1 &&
test_tick &&
git commit -a -m repo &&
the_first_commit=$(git show-ref -s --verify refs/heads/main) &&
>path2 &&
git add path2 &&
test_tick &&
git commit -a -m second &&
the_commit=$(git show-ref -s --verify refs/heads/main)
'
test_expect_success 'fetch without wildcard' '
mk_empty testrepo &&
(
cd testrepo &&
git fetch .. refs/heads/main:refs/remotes/origin/main &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
)
'
test_expect_success 'fetch with wildcard' '
mk_empty testrepo &&
(
cd testrepo &&
git config remote.up.url .. &&
git config remote.up.fetch "refs/heads/*:refs/remotes/origin/*" &&
git fetch up &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
)
'
test_expect_success 'fetch with insteadOf' '
mk_empty testrepo &&
(
TRASH=$(pwd)/ &&
cd testrepo &&
git config "url.$TRASH.insteadOf" trash/ &&
git config remote.up.url trash/. &&
git config remote.up.fetch "refs/heads/*:refs/remotes/origin/*" &&
git fetch up &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
)
'
test_expect_success 'fetch with pushInsteadOf (should not rewrite)' '
mk_empty testrepo &&
(
TRASH=$(pwd)/ &&
cd testrepo &&
git config "url.trash/.pushInsteadOf" "$TRASH" &&
git config remote.up.url "$TRASH." &&
git config remote.up.fetch "refs/heads/*:refs/remotes/origin/*" &&
git fetch up &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
)
'
grep_wrote () {
object_count=$1
file_name=$2
grep 'write_pack_file/wrote.*"value":"'$1'"' $2
}
test_expect_success 'push with negotiation' '
# Without negotiation
mk_empty testrepo &&
git push testrepo $the_first_commit:refs/remotes/origin/first_commit &&
git -C testrepo config receive.hideRefs refs/remotes/origin/first_commit &&
echo now pushing without negotiation &&
GIT_TRACE2_EVENT="$(pwd)/event" git -c protocol.version=2 push testrepo refs/heads/main:refs/remotes/origin/main &&
grep_wrote 5 event && # 2 commits, 2 trees, 1 blob
# Same commands, but with negotiation
rm event &&
mk_empty testrepo &&
git push testrepo $the_first_commit:refs/remotes/origin/first_commit &&
git -C testrepo config receive.hideRefs refs/remotes/origin/first_commit &&
GIT_TRACE2_EVENT="$(pwd)/event" git -c protocol.version=2 -c push.negotiate=1 push testrepo refs/heads/main:refs/remotes/origin/main &&
grep_wrote 2 event # 1 commit, 1 tree
'
test_expect_success 'push with negotiation proceeds anyway even if negotiation fails' '
rm event &&
mk_empty testrepo &&
git push testrepo $the_first_commit:refs/remotes/origin/first_commit &&
git -C testrepo config receive.hideRefs refs/remotes/origin/first_commit &&
GIT_TEST_PROTOCOL_VERSION=0 GIT_TRACE2_EVENT="$(pwd)/event" \
git -c push.negotiate=1 push testrepo refs/heads/main:refs/remotes/origin/main 2>err &&
grep_wrote 5 event && # 2 commits, 2 trees, 1 blob
test_i18ngrep "push negotiation failed" err
'
test_expect_success 'push without wildcard' '
mk_empty testrepo &&
git push testrepo refs/heads/main:refs/remotes/origin/main &&
(
cd testrepo &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
)
'
test_expect_success 'push with wildcard' '
mk_empty testrepo &&
git push testrepo "refs/heads/*:refs/remotes/origin/*" &&
(
cd testrepo &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
)
'
test_expect_success 'push with insteadOf' '
mk_empty testrepo &&
TRASH="$(pwd)/" &&
test_config "url.$TRASH.insteadOf" trash/ &&
git push trash/testrepo refs/heads/main:refs/remotes/origin/main &&
(
cd testrepo &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
)
'
test_expect_success 'push with pushInsteadOf' '
mk_empty testrepo &&
TRASH="$(pwd)/" &&
test_config "url.$TRASH.pushInsteadOf" trash/ &&
git push trash/testrepo refs/heads/main:refs/remotes/origin/main &&
(
cd testrepo &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
)
'
test_expect_success 'push with pushInsteadOf and explicit pushurl (pushInsteadOf should not rewrite)' '
mk_empty testrepo &&
test_config "url.trash2/.pushInsteadOf" testrepo/ &&
test_config "url.trash3/.pushInsteadOf" trash/wrong &&
test_config remote.r.url trash/wrong &&
test_config remote.r.pushurl "testrepo/" &&
git push r refs/heads/main:refs/remotes/origin/main &&
(
cd testrepo &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
)
'
test_expect_success 'push with matching heads' '
mk_test testrepo heads/main &&
git push testrepo : &&
check_push_result testrepo $the_commit heads/main
'
test_expect_success 'push with matching heads on the command line' '
mk_test testrepo heads/main &&
git push testrepo : &&
check_push_result testrepo $the_commit heads/main
'
test_expect_success 'failed (non-fast-forward) push with matching heads' '
mk_test testrepo heads/main &&
git push testrepo : &&
git commit --amend -massaged &&
test_must_fail git push testrepo &&
check_push_result testrepo $the_commit heads/main &&
git reset --hard $the_commit
'
test_expect_success 'push --force with matching heads' '
mk_test testrepo heads/main &&
git push testrepo : &&
git commit --amend -massaged &&
git push --force testrepo : &&
! check_push_result testrepo $the_commit heads/main &&
git reset --hard $the_commit
'
test_expect_success 'push with matching heads and forced update' '
mk_test testrepo heads/main &&
git push testrepo : &&
git commit --amend -massaged &&
git push testrepo +: &&
! check_push_result testrepo $the_commit heads/main &&
git reset --hard $the_commit
'
test_expect_success 'push with no ambiguity (1)' '
mk_test testrepo heads/main &&
git push testrepo main:main &&
check_push_result testrepo $the_commit heads/main
'
test_expect_success 'push with no ambiguity (2)' '
mk_test testrepo remotes/origin/main &&
git push testrepo main:origin/main &&
check_push_result testrepo $the_commit remotes/origin/main
'
test_expect_success 'push with colon-less refspec, no ambiguity' '
mk_test testrepo heads/main heads/t/main &&
git branch -f t/main main &&
git push testrepo main &&
check_push_result testrepo $the_commit heads/main &&
check_push_result testrepo $the_first_commit heads/t/main
'
test_expect_success 'push with weak ambiguity (1)' '
mk_test testrepo heads/main remotes/origin/main &&
git push testrepo main:main &&
check_push_result testrepo $the_commit heads/main &&
check_push_result testrepo $the_first_commit remotes/origin/main
'
test_expect_success 'push with weak ambiguity (2)' '
mk_test testrepo heads/main remotes/origin/main remotes/another/main &&
git push testrepo main:main &&
check_push_result testrepo $the_commit heads/main &&
check_push_result testrepo $the_first_commit remotes/origin/main remotes/another/main
'
test_expect_success 'push with ambiguity' '
mk_test testrepo heads/frotz tags/frotz &&
test_must_fail git push testrepo main:frotz &&
check_push_result testrepo $the_first_commit heads/frotz tags/frotz
'
test_expect_success 'push with colon-less refspec (1)' '
mk_test testrepo heads/frotz tags/frotz &&
git branch -f frotz main &&
git push testrepo frotz &&
check_push_result testrepo $the_commit heads/frotz &&
check_push_result testrepo $the_first_commit tags/frotz
'
test_expect_success 'push with colon-less refspec (2)' '
mk_test testrepo heads/frotz tags/frotz &&
if git show-ref --verify -q refs/heads/frotz
then
git branch -D frotz
fi &&
git tag -f frotz &&
git push -f testrepo frotz &&
check_push_result testrepo $the_commit tags/frotz &&
check_push_result testrepo $the_first_commit heads/frotz
'
test_expect_success 'push with colon-less refspec (3)' '
mk_test testrepo &&
if git show-ref --verify -q refs/tags/frotz
then
git tag -d frotz
fi &&
git branch -f frotz main &&
git push testrepo frotz &&
check_push_result testrepo $the_commit heads/frotz &&
test 1 = $( cd testrepo && git show-ref | wc -l )
'
test_expect_success 'push with colon-less refspec (4)' '
mk_test testrepo &&
if git show-ref --verify -q refs/heads/frotz
then
git branch -D frotz
fi &&
git tag -f frotz &&
git push testrepo frotz &&
check_push_result testrepo $the_commit tags/frotz &&
test 1 = $( cd testrepo && git show-ref | wc -l )
'
test_expect_success 'push head with non-existent, incomplete dest' '
mk_test testrepo &&
git push testrepo main:branch &&
check_push_result testrepo $the_commit heads/branch
'
test_expect_success 'push tag with non-existent, incomplete dest' '
mk_test testrepo &&
git tag -f v1.0 &&
git push testrepo v1.0:tag &&
check_push_result testrepo $the_commit tags/tag
'
test_expect_success 'push sha1 with non-existent, incomplete dest' '
mk_test testrepo &&
test_must_fail git push testrepo $(git rev-parse main):foo
'
test_expect_success 'push ref expression with non-existent, incomplete dest' '
mk_test testrepo &&
test_must_fail git push testrepo main^:branch
'
for head in HEAD @
do
test_expect_success "push with $head" '
2021-01-26 01:19:18 +03:00
mk_test testrepo heads/main &&
git checkout main &&
git push testrepo $head &&
2021-01-26 01:19:18 +03:00
check_push_result testrepo $the_commit heads/main
'
test_expect_success "push with $head nonexisting at remote" '
2021-01-26 01:19:18 +03:00
mk_test testrepo heads/main &&
git checkout -b local main &&
test_when_finished "git checkout main; git branch -D local" &&
git push testrepo $head &&
check_push_result testrepo $the_commit heads/local
'
test_expect_success "push with +$head" '
2021-01-26 01:19:18 +03:00
mk_test testrepo heads/main &&
git checkout -b local main &&
test_when_finished "git checkout main; git branch -D local" &&
git push testrepo main local &&
check_push_result testrepo $the_commit heads/main &&
check_push_result testrepo $the_commit heads/local &&
# Without force rewinding should fail
git reset --hard $head^ &&
test_must_fail git push testrepo $head &&
check_push_result testrepo $the_commit heads/local &&
# With force rewinding should succeed
git push testrepo +$head &&
check_push_result testrepo $the_first_commit heads/local
'
test_expect_success "push $head with non-existent, incomplete dest" '
mk_test testrepo &&
2021-01-26 01:19:18 +03:00
git checkout main &&
git push testrepo $head:branch &&
check_push_result testrepo $the_commit heads/branch
'
test_expect_success "push with config remote.*.push = $head" '
mk_test testrepo heads/local &&
2021-01-26 01:19:18 +03:00
git checkout main &&
git branch -f local $the_commit &&
test_when_finished "git branch -D local" &&
(
cd testrepo &&
git checkout local &&
git reset --hard $the_first_commit
) &&
test_config remote.there.url testrepo &&
test_config remote.there.push $head &&
2021-01-26 01:19:18 +03:00
test_config branch.main.remote there &&
git push &&
2021-01-26 01:19:18 +03:00
check_push_result testrepo $the_commit heads/main &&
check_push_result testrepo $the_first_commit heads/local
'
done
test_expect_success 'push with remote.pushdefault' '
mk_test up_repo heads/main &&
mk_test down_repo heads/main &&
test_config remote.up.url up_repo &&
test_config remote.down.url down_repo &&
test_config branch.main.remote up &&
test_config remote.pushdefault down &&
test_config push.default matching &&
git push &&
check_push_result up_repo $the_first_commit heads/main &&
check_push_result down_repo $the_commit heads/main
'
test_expect_success 'push with config remote.*.pushurl' '
mk_test testrepo heads/main &&
git checkout main &&
test_config remote.there.url test2repo &&
test_config remote.there.pushurl testrepo &&
git push there : &&
check_push_result testrepo $the_commit heads/main
'
test_expect_success 'push with config branch.*.pushremote' '
mk_test up_repo heads/main &&
mk_test side_repo heads/main &&
mk_test down_repo heads/main &&
test_config remote.up.url up_repo &&
test_config remote.pushdefault side_repo &&
test_config remote.down.url down_repo &&
test_config branch.main.remote up &&
test_config branch.main.pushremote down &&
test_config push.default matching &&
git push &&
check_push_result up_repo $the_first_commit heads/main &&
check_push_result side_repo $the_first_commit heads/main &&
check_push_result down_repo $the_commit heads/main
'
test_expect_success 'branch.*.pushremote config order is irrelevant' '
mk_test one_repo heads/main &&
mk_test two_repo heads/main &&
test_config remote.one.url one_repo &&
test_config remote.two.url two_repo &&
test_config branch.main.pushremote two_repo &&
test_config remote.pushdefault one_repo &&
test_config push.default matching &&
git push &&
check_push_result one_repo $the_first_commit heads/main &&
check_push_result two_repo $the_commit heads/main
'
test_expect_success 'push with dry-run' '
mk_test testrepo heads/main &&
old_commit=$(git -C testrepo show-ref -s --verify refs/heads/main) &&
git push --dry-run testrepo : &&
check_push_result testrepo $old_commit heads/main
'
test_expect_success 'push updates local refs' '
mk_test testrepo heads/main &&
mk_child testrepo child &&
(
cd child &&
git pull .. main &&
git push &&
test $(git rev-parse main) = \
$(git rev-parse remotes/origin/main)
)
'
test_expect_success 'push updates up-to-date local refs' '
mk_test testrepo heads/main &&
mk_child testrepo child1 &&
mk_child testrepo child2 &&
(cd child1 && git pull .. main && git push) &&
(
cd child2 &&
git pull ../child1 main &&
git push &&
test $(git rev-parse main) = \
$(git rev-parse remotes/origin/main)
)
'
test_expect_success 'push preserves up-to-date packed refs' '
mk_test testrepo heads/main &&
mk_child testrepo child &&
(
cd child &&
git push &&
! test -f .git/refs/remotes/origin/main
)
'
test_expect_success 'push does not update local refs on failure' '
mk_test testrepo heads/main &&
mk_child testrepo child &&
mkdir testrepo/.git/hooks &&
echo "#!/no/frobnication/today" >testrepo/.git/hooks/pre-receive &&
chmod +x testrepo/.git/hooks/pre-receive &&
(
cd child &&
git pull .. main &&
test_must_fail git push &&
test $(git rev-parse main) != \
$(git rev-parse remotes/origin/main)
)
'
test_expect_success 'allow deleting an invalid remote ref' '
mk_test testrepo heads/main &&
rm -f testrepo/.git/objects/??/* &&
git push testrepo :refs/heads/main &&
(cd testrepo && test_must_fail git rev-parse --verify refs/heads/main)
'
test_expect_success 'pushing valid refs triggers post-receive and post-update hooks' '
mk_test_with_hooks testrepo heads/main heads/next &&
orgmain=$(cd testrepo && git show-ref -s --verify refs/heads/main) &&
newmain=$(git show-ref -s --verify refs/heads/main) &&
orgnext=$(cd testrepo && git show-ref -s --verify refs/heads/next) &&
newnext=$ZERO_OID &&
git push testrepo refs/heads/main:refs/heads/main :refs/heads/next &&
(
cd testrepo/.git &&
cat >pre-receive.expect <<-EOF &&
$orgmain $newmain refs/heads/main
$orgnext $newnext refs/heads/next
EOF
cat >update.expect <<-EOF &&
refs/heads/main $orgmain $newmain
refs/heads/next $orgnext $newnext
EOF
cat >post-receive.expect <<-EOF &&
$orgmain $newmain refs/heads/main
$orgnext $newnext refs/heads/next
EOF
cat >post-update.expect <<-EOF &&
refs/heads/main
refs/heads/next
EOF
test_cmp pre-receive.expect pre-receive.actual &&
test_cmp update.expect update.actual &&
test_cmp post-receive.expect post-receive.actual &&
test_cmp post-update.expect post-update.actual
)
'
test_expect_success 'deleting dangling ref triggers hooks with correct args' '
mk_test_with_hooks testrepo heads/main &&
rm -f testrepo/.git/objects/??/* &&
git push testrepo :refs/heads/main &&
(
cd testrepo/.git &&
cat >pre-receive.expect <<-EOF &&
$ZERO_OID $ZERO_OID refs/heads/main
EOF
cat >update.expect <<-EOF &&
refs/heads/main $ZERO_OID $ZERO_OID
EOF
cat >post-receive.expect <<-EOF &&
$ZERO_OID $ZERO_OID refs/heads/main
EOF
cat >post-update.expect <<-EOF &&
refs/heads/main
EOF
test_cmp pre-receive.expect pre-receive.actual &&
test_cmp update.expect update.actual &&
test_cmp post-receive.expect post-receive.actual &&
test_cmp post-update.expect post-update.actual
)
'
test_expect_success 'deletion of a non-existent ref is not fed to post-receive and post-update hooks' '
mk_test_with_hooks testrepo heads/main &&
orgmain=$(cd testrepo && git show-ref -s --verify refs/heads/main) &&
newmain=$(git show-ref -s --verify refs/heads/main) &&
git push testrepo main :refs/heads/nonexistent &&
(
cd testrepo/.git &&
cat >pre-receive.expect <<-EOF &&
$orgmain $newmain refs/heads/main
$ZERO_OID $ZERO_OID refs/heads/nonexistent
EOF
cat >update.expect <<-EOF &&
refs/heads/main $orgmain $newmain
refs/heads/nonexistent $ZERO_OID $ZERO_OID
EOF
cat >post-receive.expect <<-EOF &&
$orgmain $newmain refs/heads/main
EOF
cat >post-update.expect <<-EOF &&
refs/heads/main
EOF
test_cmp pre-receive.expect pre-receive.actual &&
test_cmp update.expect update.actual &&
test_cmp post-receive.expect post-receive.actual &&
test_cmp post-update.expect post-update.actual
)
'
test_expect_success 'deletion of a non-existent ref alone does trigger post-receive and post-update hooks' '
mk_test_with_hooks testrepo heads/main &&
git push testrepo :refs/heads/nonexistent &&
(
cd testrepo/.git &&
cat >pre-receive.expect <<-EOF &&
$ZERO_OID $ZERO_OID refs/heads/nonexistent
EOF
cat >update.expect <<-EOF &&
refs/heads/nonexistent $ZERO_OID $ZERO_OID
EOF
test_cmp pre-receive.expect pre-receive.actual &&
test_cmp update.expect update.actual &&
test_path_is_missing post-receive.actual &&
test_path_is_missing post-update.actual
)
'
test_expect_success 'mixed ref updates, deletes, invalid deletes trigger hooks with correct input' '
mk_test_with_hooks testrepo heads/main heads/next heads/seen &&
orgmain=$(cd testrepo && git show-ref -s --verify refs/heads/main) &&
newmain=$(git show-ref -s --verify refs/heads/main) &&
orgnext=$(cd testrepo && git show-ref -s --verify refs/heads/next) &&
newnext=$ZERO_OID &&
orgseen=$(cd testrepo && git show-ref -s --verify refs/heads/seen) &&
newseen=$(git show-ref -s --verify refs/heads/main) &&
git push testrepo refs/heads/main:refs/heads/main \
refs/heads/main:refs/heads/seen :refs/heads/next \
:refs/heads/nonexistent &&
(
cd testrepo/.git &&
cat >pre-receive.expect <<-EOF &&
$orgmain $newmain refs/heads/main
$orgnext $newnext refs/heads/next
$orgseen $newseen refs/heads/seen
$ZERO_OID $ZERO_OID refs/heads/nonexistent
EOF
cat >update.expect <<-EOF &&
refs/heads/main $orgmain $newmain
refs/heads/next $orgnext $newnext
refs/heads/seen $orgseen $newseen
refs/heads/nonexistent $ZERO_OID $ZERO_OID
EOF
cat >post-receive.expect <<-EOF &&
$orgmain $newmain refs/heads/main
$orgnext $newnext refs/heads/next
$orgseen $newseen refs/heads/seen
EOF
cat >post-update.expect <<-EOF &&
refs/heads/main
refs/heads/next
refs/heads/seen
EOF
test_cmp pre-receive.expect pre-receive.actual &&
test_cmp update.expect update.actual &&
test_cmp post-receive.expect post-receive.actual &&
test_cmp post-update.expect post-update.actual
)
'
test_expect_success 'allow deleting a ref using --delete' '
mk_test testrepo heads/main &&
(cd testrepo && git config receive.denyDeleteCurrent warn) &&
git push testrepo --delete main &&
(cd testrepo && test_must_fail git rev-parse --verify refs/heads/main)
'
test_expect_success 'allow deleting a tag using --delete' '
mk_test testrepo heads/main &&
git tag -a -m dummy_message deltag heads/main &&
git push testrepo --tags &&
(cd testrepo && git rev-parse --verify -q refs/tags/deltag) &&
git push testrepo --delete tag deltag &&
(cd testrepo && test_must_fail git rev-parse --verify refs/tags/deltag)
'
test_expect_success 'push --delete without args aborts' '
mk_test testrepo heads/main &&
test_must_fail git push testrepo --delete
'
test_expect_success 'push --delete refuses src:dest refspecs' '
mk_test testrepo heads/main &&
test_must_fail git push testrepo --delete main:foo
'
test_expect_success 'push --delete refuses empty string' '
mk_test testrepo heads/master &&
test_must_fail git push testrepo --delete ""
'
test_expect_success 'warn on push to HEAD of non-bare repository' '
mk_test testrepo heads/main &&
(
cd testrepo &&
git checkout main &&
git config receive.denyCurrentBranch warn
) &&
git push testrepo main 2>stderr &&
grep "warning: updating the current branch" stderr
'
test_expect_success 'deny push to HEAD of non-bare repository' '
mk_test testrepo heads/main &&
(
cd testrepo &&
git checkout main &&
git config receive.denyCurrentBranch true
) &&
test_must_fail git push testrepo main
'
test_expect_success 'allow push to HEAD of bare repository (bare)' '
mk_test testrepo heads/main &&
(
cd testrepo &&
git checkout main &&
git config receive.denyCurrentBranch true &&
git config core.bare true
) &&
git push testrepo main 2>stderr &&
! grep "warning: updating the current branch" stderr
'
test_expect_success 'allow push to HEAD of non-bare repository (config)' '
mk_test testrepo heads/main &&
(
cd testrepo &&
git checkout main &&
git config receive.denyCurrentBranch false
) &&
git push testrepo main 2>stderr &&
! grep "warning: updating the current branch" stderr
'
test_expect_success 'fetch with branches' '
mk_empty testrepo &&
git branch second $the_first_commit &&
git checkout second &&
echo ".." > testrepo/.git/branches/branch1 &&
(
cd testrepo &&
git fetch branch1 &&
echo "$the_commit commit refs/heads/branch1" >expect &&
git for-each-ref refs/heads >actual &&
test_cmp expect actual
) &&
git checkout main
'
test_expect_success 'fetch with branches containing #' '
mk_empty testrepo &&
echo "..#second" > testrepo/.git/branches/branch2 &&
(
cd testrepo &&
git fetch branch2 &&
echo "$the_first_commit commit refs/heads/branch2" >expect &&
git for-each-ref refs/heads >actual &&
test_cmp expect actual
) &&
git checkout main
'
test_expect_success 'push with branches' '
mk_empty testrepo &&
git checkout second &&
echo "testrepo" > .git/branches/branch1 &&
git push branch1 &&
(
cd testrepo &&
echo "$the_first_commit commit refs/heads/main" >expect &&
git for-each-ref refs/heads >actual &&
test_cmp expect actual
)
'
test_expect_success 'push with branches containing #' '
mk_empty testrepo &&
echo "testrepo#branch3" > .git/branches/branch2 &&
git push branch2 &&
(
cd testrepo &&
echo "$the_first_commit commit refs/heads/branch3" >expect &&
git for-each-ref refs/heads >actual &&
test_cmp expect actual
) &&
git checkout main
'
receive-pack: detect aliased updates which can occur with symrefs When pushing to a remote repo the sending side filters out aliased updates (e.g., foo:baz bar:baz). However, it is not possible for the sender to know if two refs are aliased on the receiving side via symrefs. Here is one such scenario: $ git init origin $ (cd origin && touch file && git add file && git commit -a -m intial) $ git clone --bare origin origin.git $ rm -rf origin $ git clone origin.git client $ git clone --mirror client backup.git && $ (cd backup.git && git remote set-head origin --auto) $ (cd client && git remote add --mirror backup ../backup.git && echo change1 > file && git commit -a -m change1 && git push origin && git push backup ) The push to backup fails with: Counting objects: 5, done. Writing objects: 100% (3/3), 244 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. error: Ref refs/remotes/origin/master is at ef3... but expected 262... remote: error: failed to lock refs/remotes/origin/master To ../backup.git 262cd57..ef307ff master -> master 262cd57..ef307ff origin/HEAD -> origin/HEAD ! [remote rejected] origin/master -> origin/master (failed to lock) error: failed to push some refs to '../backup.git' The reason is that refs/remotes/origin/HEAD is a symref to refs/remotes/origin/master, but it is not possible for the sending side to unambiguously know this. This commit fixes the issue by having receive-pack ignore any update to a symref whose target is being identically updated. If a symref and its target are being updated inconsistently, then the update for both fails with an error message ("refusing inconsistent update...") to help diagnose the situation. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 02:19:18 +04:00
test_expect_success 'push into aliased refs (consistent)' '
mk_test testrepo heads/main &&
mk_child testrepo child1 &&
mk_child testrepo child2 &&
receive-pack: detect aliased updates which can occur with symrefs When pushing to a remote repo the sending side filters out aliased updates (e.g., foo:baz bar:baz). However, it is not possible for the sender to know if two refs are aliased on the receiving side via symrefs. Here is one such scenario: $ git init origin $ (cd origin && touch file && git add file && git commit -a -m intial) $ git clone --bare origin origin.git $ rm -rf origin $ git clone origin.git client $ git clone --mirror client backup.git && $ (cd backup.git && git remote set-head origin --auto) $ (cd client && git remote add --mirror backup ../backup.git && echo change1 > file && git commit -a -m change1 && git push origin && git push backup ) The push to backup fails with: Counting objects: 5, done. Writing objects: 100% (3/3), 244 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. error: Ref refs/remotes/origin/master is at ef3... but expected 262... remote: error: failed to lock refs/remotes/origin/master To ../backup.git 262cd57..ef307ff master -> master 262cd57..ef307ff origin/HEAD -> origin/HEAD ! [remote rejected] origin/master -> origin/master (failed to lock) error: failed to push some refs to '../backup.git' The reason is that refs/remotes/origin/HEAD is a symref to refs/remotes/origin/master, but it is not possible for the sending side to unambiguously know this. This commit fixes the issue by having receive-pack ignore any update to a symref whose target is being identically updated. If a symref and its target are being updated inconsistently, then the update for both fails with an error message ("refusing inconsistent update...") to help diagnose the situation. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 02:19:18 +04:00
(
cd child1 &&
git branch foo &&
git symbolic-ref refs/heads/bar refs/heads/foo &&
receive-pack: detect aliased updates which can occur with symrefs When pushing to a remote repo the sending side filters out aliased updates (e.g., foo:baz bar:baz). However, it is not possible for the sender to know if two refs are aliased on the receiving side via symrefs. Here is one such scenario: $ git init origin $ (cd origin && touch file && git add file && git commit -a -m intial) $ git clone --bare origin origin.git $ rm -rf origin $ git clone origin.git client $ git clone --mirror client backup.git && $ (cd backup.git && git remote set-head origin --auto) $ (cd client && git remote add --mirror backup ../backup.git && echo change1 > file && git commit -a -m change1 && git push origin && git push backup ) The push to backup fails with: Counting objects: 5, done. Writing objects: 100% (3/3), 244 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. error: Ref refs/remotes/origin/master is at ef3... but expected 262... remote: error: failed to lock refs/remotes/origin/master To ../backup.git 262cd57..ef307ff master -> master 262cd57..ef307ff origin/HEAD -> origin/HEAD ! [remote rejected] origin/master -> origin/master (failed to lock) error: failed to push some refs to '../backup.git' The reason is that refs/remotes/origin/HEAD is a symref to refs/remotes/origin/master, but it is not possible for the sending side to unambiguously know this. This commit fixes the issue by having receive-pack ignore any update to a symref whose target is being identically updated. If a symref and its target are being updated inconsistently, then the update for both fails with an error message ("refusing inconsistent update...") to help diagnose the situation. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 02:19:18 +04:00
git config receive.denyCurrentBranch false
) &&
(
cd child2 &&
>path2 &&
git add path2 &&
test_tick &&
git commit -a -m child2 &&
git branch foo &&
git branch bar &&
git push ../child1 foo bar
)
'
test_expect_success 'push into aliased refs (inconsistent)' '
mk_test testrepo heads/main &&
mk_child testrepo child1 &&
mk_child testrepo child2 &&
receive-pack: detect aliased updates which can occur with symrefs When pushing to a remote repo the sending side filters out aliased updates (e.g., foo:baz bar:baz). However, it is not possible for the sender to know if two refs are aliased on the receiving side via symrefs. Here is one such scenario: $ git init origin $ (cd origin && touch file && git add file && git commit -a -m intial) $ git clone --bare origin origin.git $ rm -rf origin $ git clone origin.git client $ git clone --mirror client backup.git && $ (cd backup.git && git remote set-head origin --auto) $ (cd client && git remote add --mirror backup ../backup.git && echo change1 > file && git commit -a -m change1 && git push origin && git push backup ) The push to backup fails with: Counting objects: 5, done. Writing objects: 100% (3/3), 244 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. error: Ref refs/remotes/origin/master is at ef3... but expected 262... remote: error: failed to lock refs/remotes/origin/master To ../backup.git 262cd57..ef307ff master -> master 262cd57..ef307ff origin/HEAD -> origin/HEAD ! [remote rejected] origin/master -> origin/master (failed to lock) error: failed to push some refs to '../backup.git' The reason is that refs/remotes/origin/HEAD is a symref to refs/remotes/origin/master, but it is not possible for the sending side to unambiguously know this. This commit fixes the issue by having receive-pack ignore any update to a symref whose target is being identically updated. If a symref and its target are being updated inconsistently, then the update for both fails with an error message ("refusing inconsistent update...") to help diagnose the situation. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 02:19:18 +04:00
(
cd child1 &&
git branch foo &&
git symbolic-ref refs/heads/bar refs/heads/foo &&
receive-pack: detect aliased updates which can occur with symrefs When pushing to a remote repo the sending side filters out aliased updates (e.g., foo:baz bar:baz). However, it is not possible for the sender to know if two refs are aliased on the receiving side via symrefs. Here is one such scenario: $ git init origin $ (cd origin && touch file && git add file && git commit -a -m intial) $ git clone --bare origin origin.git $ rm -rf origin $ git clone origin.git client $ git clone --mirror client backup.git && $ (cd backup.git && git remote set-head origin --auto) $ (cd client && git remote add --mirror backup ../backup.git && echo change1 > file && git commit -a -m change1 && git push origin && git push backup ) The push to backup fails with: Counting objects: 5, done. Writing objects: 100% (3/3), 244 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. error: Ref refs/remotes/origin/master is at ef3... but expected 262... remote: error: failed to lock refs/remotes/origin/master To ../backup.git 262cd57..ef307ff master -> master 262cd57..ef307ff origin/HEAD -> origin/HEAD ! [remote rejected] origin/master -> origin/master (failed to lock) error: failed to push some refs to '../backup.git' The reason is that refs/remotes/origin/HEAD is a symref to refs/remotes/origin/master, but it is not possible for the sending side to unambiguously know this. This commit fixes the issue by having receive-pack ignore any update to a symref whose target is being identically updated. If a symref and its target are being updated inconsistently, then the update for both fails with an error message ("refusing inconsistent update...") to help diagnose the situation. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-20 02:19:18 +04:00
git config receive.denyCurrentBranch false
) &&
(
cd child2 &&
>path2 &&
git add path2 &&
test_tick &&
git commit -a -m child2 &&
git branch foo &&
>path3 &&
git add path3 &&
test_tick &&
git commit -a -m child2 &&
git branch bar &&
test_must_fail git push ../child1 foo bar 2>stderr &&
grep "refusing inconsistent update" stderr
)
'
test_force_push_tag () {
tag_type_description=$1
tag_args=$2
test_expect_success "force pushing required to update $tag_type_description" "
mk_test testrepo heads/main &&
mk_child testrepo child1 &&
mk_child testrepo child2 &&
(
cd child1 &&
git tag testTag &&
git push ../child2 testTag &&
>file1 &&
git add file1 &&
git commit -m 'file1' &&
git tag $tag_args testTag &&
test_must_fail git push ../child2 testTag &&
git push --force ../child2 testTag &&
git tag $tag_args testTag HEAD~ &&
test_must_fail git push ../child2 testTag &&
git push --force ../child2 testTag &&
# Clobbering without + in refspec needs --force
git tag -f testTag &&
test_must_fail git push ../child2 'refs/tags/*:refs/tags/*' &&
git push --force ../child2 'refs/tags/*:refs/tags/*' &&
# Clobbering with + in refspec does not need --force
git tag -f testTag HEAD~ &&
git push ../child2 '+refs/tags/*:refs/tags/*' &&
# Clobbering with --no-force still obeys + in refspec
git tag -f testTag &&
git push --no-force ../child2 '+refs/tags/*:refs/tags/*' &&
# Clobbering with/without --force and 'tag <name>' format
git tag -f testTag HEAD~ &&
test_must_fail git push ../child2 tag testTag &&
git push --force ../child2 tag testTag
)
"
}
test_force_push_tag "lightweight tag" "-f"
test_force_push_tag "annotated tag" "-f -a -m'tag message'"
test_force_fetch_tag () {
tag_type_description=$1
tag_args=$2
fetch: stop clobbering existing tags without --force Change "fetch" to treat "+" in refspecs (aka --force) to mean we should clobber a local tag of the same name. This changes the long-standing behavior of "fetch" added in 853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20). Before this change, all tag fetches effectively had --force enabled. See the git-fetch-script code in fast_forward_local() with the comment: > Tags need not be pointing at commits so there is no way to > guarantee "fast-forward" anyway. That commit and the rest of the history of "fetch" shows that the "+" (--force) part of refpecs was only conceived for branch updates, while tags have accepted any changes from upstream unconditionally and clobbered the local tag object. Changing this behavior has been discussed as early as 2011[1]. The current behavior doesn't make sense to me, it easily results in local tags accidentally being clobbered. We could namespace our tags per-remote and not locally populate refs/tags/*, but as with my 97716d217c ("fetch: add a --prune-tags option and fetch.pruneTags config", 2018-02-09) it's easier to work around the current implementation than to fix the root cause. So this change implements suggestion #1 from Jeff's 2011 E-Mail[1], "fetch" now only clobbers the tag if either "+" is provided as part of the refspec, or if "--force" is provided on the command-line. This also makes it nicely symmetrical with how "tag" itself works when creating tags. I.e. we refuse to clobber any existing tags unless "--force" is supplied. Now we can refuse all such clobbering, whether it would happen by clobbering a local tag with "tag", or by fetching it from the remote with "fetch". Ref updates outside refs/{tags,heads/* are still still not symmetrical with how "git push" works, as discussed in the recently changed pull-fetch-param.txt documentation. This change brings the two divergent behaviors more into line with one another. I don't think there's any reason "fetch" couldn't fully converge with the behavior used by "push", but that's a topic for another change. One of the tests added in 31b808a032 ("clone --single: limit the fetch refspec to fetched branch", 2012-09-20) is being changed to use --force where a clone would clobber a tag. This changes nothing about the existing behavior of the test. 1. https://public-inbox.org/git/20111123221658.GA22313@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31 23:10:04 +03:00
test_expect_success "fetch will not clobber an existing $tag_type_description without --force" "
mk_test testrepo heads/main &&
mk_child testrepo child1 &&
mk_child testrepo child2 &&
(
cd testrepo &&
git tag testTag &&
git -C ../child1 fetch origin tag testTag &&
>file1 &&
git add file1 &&
git commit -m 'file1' &&
git tag $tag_args testTag &&
fetch: stop clobbering existing tags without --force Change "fetch" to treat "+" in refspecs (aka --force) to mean we should clobber a local tag of the same name. This changes the long-standing behavior of "fetch" added in 853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20). Before this change, all tag fetches effectively had --force enabled. See the git-fetch-script code in fast_forward_local() with the comment: > Tags need not be pointing at commits so there is no way to > guarantee "fast-forward" anyway. That commit and the rest of the history of "fetch" shows that the "+" (--force) part of refpecs was only conceived for branch updates, while tags have accepted any changes from upstream unconditionally and clobbered the local tag object. Changing this behavior has been discussed as early as 2011[1]. The current behavior doesn't make sense to me, it easily results in local tags accidentally being clobbered. We could namespace our tags per-remote and not locally populate refs/tags/*, but as with my 97716d217c ("fetch: add a --prune-tags option and fetch.pruneTags config", 2018-02-09) it's easier to work around the current implementation than to fix the root cause. So this change implements suggestion #1 from Jeff's 2011 E-Mail[1], "fetch" now only clobbers the tag if either "+" is provided as part of the refspec, or if "--force" is provided on the command-line. This also makes it nicely symmetrical with how "tag" itself works when creating tags. I.e. we refuse to clobber any existing tags unless "--force" is supplied. Now we can refuse all such clobbering, whether it would happen by clobbering a local tag with "tag", or by fetching it from the remote with "fetch". Ref updates outside refs/{tags,heads/* are still still not symmetrical with how "git push" works, as discussed in the recently changed pull-fetch-param.txt documentation. This change brings the two divergent behaviors more into line with one another. I don't think there's any reason "fetch" couldn't fully converge with the behavior used by "push", but that's a topic for another change. One of the tests added in 31b808a032 ("clone --single: limit the fetch refspec to fetched branch", 2012-09-20) is being changed to use --force where a clone would clobber a tag. This changes nothing about the existing behavior of the test. 1. https://public-inbox.org/git/20111123221658.GA22313@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31 23:10:04 +03:00
test_must_fail git -C ../child1 fetch origin tag testTag &&
git -C ../child1 fetch origin '+refs/tags/*:refs/tags/*'
)
"
}
test_force_fetch_tag "lightweight tag" "-f"
test_force_fetch_tag "annotated tag" "-f -a -m'tag message'"
test_expect_success 'push --porcelain' '
mk_empty testrepo &&
echo >.git/foo "To testrepo" &&
echo >>.git/foo "* refs/heads/main:refs/remotes/origin/main [new reference]" &&
echo >>.git/foo "Done" &&
git push >.git/bar --porcelain testrepo refs/heads/main:refs/remotes/origin/main &&
(
cd testrepo &&
echo "$the_commit commit refs/remotes/origin/main" >expect &&
git for-each-ref refs/remotes/origin >actual &&
test_cmp expect actual
) &&
test_cmp .git/foo .git/bar
'
test_expect_success 'push --porcelain bad url' '
mk_empty testrepo &&
test_must_fail git push >.git/bar --porcelain asdfasdfasd refs/heads/main:refs/remotes/origin/main &&
! grep -q Done .git/bar
'
test_expect_success 'push --porcelain rejected' '
mk_empty testrepo &&
git push testrepo refs/heads/main:refs/remotes/origin/main &&
(cd testrepo &&
git reset --hard origin/main^ &&
git config receive.denyCurrentBranch true) &&
echo >.git/foo "To testrepo" &&
echo >>.git/foo "! refs/heads/main:refs/heads/main [remote rejected] (branch is currently checked out)" &&
echo >>.git/foo "Done" &&
test_must_fail git push >.git/bar --porcelain testrepo refs/heads/main:refs/heads/main &&
test_cmp .git/foo .git/bar
'
test_expect_success 'push --porcelain --dry-run rejected' '
mk_empty testrepo &&
git push testrepo refs/heads/main:refs/remotes/origin/main &&
(cd testrepo &&
git reset --hard origin/main &&
git config receive.denyCurrentBranch true) &&
echo >.git/foo "To testrepo" &&
echo >>.git/foo "! refs/heads/main^:refs/heads/main [rejected] (non-fast-forward)" &&
echo >>.git/foo "Done" &&
test_must_fail git push >.git/bar --porcelain --dry-run testrepo refs/heads/main^:refs/heads/main &&
test_cmp .git/foo .git/bar
'
test_expect_success 'push --prune' '
mk_test testrepo heads/main heads/second heads/foo heads/bar &&
git push --prune testrepo : &&
check_push_result testrepo $the_commit heads/main &&
check_push_result testrepo $the_first_commit heads/second &&
! check_push_result testrepo $the_first_commit heads/foo heads/bar
'
test_expect_success 'push --prune refspec' '
mk_test testrepo tmp/main tmp/second tmp/foo tmp/bar &&
git push --prune testrepo "refs/heads/*:refs/tmp/*" &&
check_push_result testrepo $the_commit tmp/main &&
check_push_result testrepo $the_first_commit tmp/second &&
! check_push_result testrepo $the_first_commit tmp/foo tmp/bar
'
upload/receive-pack: allow hiding ref hierarchies A repository may have refs that are only used for its internal bookkeeping purposes that should not be exposed to the others that come over the network. Teach upload-pack to omit some refs from its initial advertisement by paying attention to the uploadpack.hiderefs multi-valued configuration variable. Do the same to receive-pack via the receive.hiderefs variable. As a convenient short-hand, allow using transfer.hiderefs to set the value to both of these variables. Any ref that is under the hierarchies listed on the value of these variable is excluded from responses to requests made by "ls-remote", "fetch", etc. (for upload-pack) and "push" (for receive-pack). Because these hidden refs do not count as OUR_REF, an attempt to fetch objects at the tip of them will be rejected, and because these refs do not get advertised, "git push :" will not see local branches that have the same name as them as "matching" ones to be sent. An attempt to update/delete these hidden refs with an explicit refspec, e.g. "git push origin :refs/hidden/22", is rejected. This is not a new restriction. To the pusher, it would appear that there is no such ref, so its push request will conclude with "Now that I sent you all the data, it is time for you to update the refs. I saw that the ref did not exist when I started pushing, and I want the result to point at this commit". The receiving end will apply the compare-and-swap rule to this request and rejects the push with "Well, your update request conflicts with somebody else; I see there is such a ref.", which is the right thing to do. Otherwise a push to a hidden ref will always be "the last one wins", which is not a good default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 04:08:30 +04:00
for configsection in transfer receive
do
test_expect_success "push to update a ref hidden by $configsection.hiderefs" '
mk_test testrepo heads/main hidden/one hidden/two hidden/three &&
upload/receive-pack: allow hiding ref hierarchies A repository may have refs that are only used for its internal bookkeeping purposes that should not be exposed to the others that come over the network. Teach upload-pack to omit some refs from its initial advertisement by paying attention to the uploadpack.hiderefs multi-valued configuration variable. Do the same to receive-pack via the receive.hiderefs variable. As a convenient short-hand, allow using transfer.hiderefs to set the value to both of these variables. Any ref that is under the hierarchies listed on the value of these variable is excluded from responses to requests made by "ls-remote", "fetch", etc. (for upload-pack) and "push" (for receive-pack). Because these hidden refs do not count as OUR_REF, an attempt to fetch objects at the tip of them will be rejected, and because these refs do not get advertised, "git push :" will not see local branches that have the same name as them as "matching" ones to be sent. An attempt to update/delete these hidden refs with an explicit refspec, e.g. "git push origin :refs/hidden/22", is rejected. This is not a new restriction. To the pusher, it would appear that there is no such ref, so its push request will conclude with "Now that I sent you all the data, it is time for you to update the refs. I saw that the ref did not exist when I started pushing, and I want the result to point at this commit". The receiving end will apply the compare-and-swap rule to this request and rejects the push with "Well, your update request conflicts with somebody else; I see there is such a ref.", which is the right thing to do. Otherwise a push to a hidden ref will always be "the last one wins", which is not a good default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 04:08:30 +04:00
(
cd testrepo &&
git config $configsection.hiderefs refs/hidden
) &&
# push to unhidden ref succeeds normally
git push testrepo main:refs/heads/main &&
check_push_result testrepo $the_commit heads/main &&
upload/receive-pack: allow hiding ref hierarchies A repository may have refs that are only used for its internal bookkeeping purposes that should not be exposed to the others that come over the network. Teach upload-pack to omit some refs from its initial advertisement by paying attention to the uploadpack.hiderefs multi-valued configuration variable. Do the same to receive-pack via the receive.hiderefs variable. As a convenient short-hand, allow using transfer.hiderefs to set the value to both of these variables. Any ref that is under the hierarchies listed on the value of these variable is excluded from responses to requests made by "ls-remote", "fetch", etc. (for upload-pack) and "push" (for receive-pack). Because these hidden refs do not count as OUR_REF, an attempt to fetch objects at the tip of them will be rejected, and because these refs do not get advertised, "git push :" will not see local branches that have the same name as them as "matching" ones to be sent. An attempt to update/delete these hidden refs with an explicit refspec, e.g. "git push origin :refs/hidden/22", is rejected. This is not a new restriction. To the pusher, it would appear that there is no such ref, so its push request will conclude with "Now that I sent you all the data, it is time for you to update the refs. I saw that the ref did not exist when I started pushing, and I want the result to point at this commit". The receiving end will apply the compare-and-swap rule to this request and rejects the push with "Well, your update request conflicts with somebody else; I see there is such a ref.", which is the right thing to do. Otherwise a push to a hidden ref will always be "the last one wins", which is not a good default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 04:08:30 +04:00
# push to update a hidden ref should fail
test_must_fail git push testrepo main:refs/hidden/one &&
check_push_result testrepo $the_first_commit hidden/one &&
upload/receive-pack: allow hiding ref hierarchies A repository may have refs that are only used for its internal bookkeeping purposes that should not be exposed to the others that come over the network. Teach upload-pack to omit some refs from its initial advertisement by paying attention to the uploadpack.hiderefs multi-valued configuration variable. Do the same to receive-pack via the receive.hiderefs variable. As a convenient short-hand, allow using transfer.hiderefs to set the value to both of these variables. Any ref that is under the hierarchies listed on the value of these variable is excluded from responses to requests made by "ls-remote", "fetch", etc. (for upload-pack) and "push" (for receive-pack). Because these hidden refs do not count as OUR_REF, an attempt to fetch objects at the tip of them will be rejected, and because these refs do not get advertised, "git push :" will not see local branches that have the same name as them as "matching" ones to be sent. An attempt to update/delete these hidden refs with an explicit refspec, e.g. "git push origin :refs/hidden/22", is rejected. This is not a new restriction. To the pusher, it would appear that there is no such ref, so its push request will conclude with "Now that I sent you all the data, it is time for you to update the refs. I saw that the ref did not exist when I started pushing, and I want the result to point at this commit". The receiving end will apply the compare-and-swap rule to this request and rejects the push with "Well, your update request conflicts with somebody else; I see there is such a ref.", which is the right thing to do. Otherwise a push to a hidden ref will always be "the last one wins", which is not a good default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 04:08:30 +04:00
# push to delete a hidden ref should fail
test_must_fail git push testrepo :refs/hidden/two &&
check_push_result testrepo $the_first_commit hidden/two &&
upload/receive-pack: allow hiding ref hierarchies A repository may have refs that are only used for its internal bookkeeping purposes that should not be exposed to the others that come over the network. Teach upload-pack to omit some refs from its initial advertisement by paying attention to the uploadpack.hiderefs multi-valued configuration variable. Do the same to receive-pack via the receive.hiderefs variable. As a convenient short-hand, allow using transfer.hiderefs to set the value to both of these variables. Any ref that is under the hierarchies listed on the value of these variable is excluded from responses to requests made by "ls-remote", "fetch", etc. (for upload-pack) and "push" (for receive-pack). Because these hidden refs do not count as OUR_REF, an attempt to fetch objects at the tip of them will be rejected, and because these refs do not get advertised, "git push :" will not see local branches that have the same name as them as "matching" ones to be sent. An attempt to update/delete these hidden refs with an explicit refspec, e.g. "git push origin :refs/hidden/22", is rejected. This is not a new restriction. To the pusher, it would appear that there is no such ref, so its push request will conclude with "Now that I sent you all the data, it is time for you to update the refs. I saw that the ref did not exist when I started pushing, and I want the result to point at this commit". The receiving end will apply the compare-and-swap rule to this request and rejects the push with "Well, your update request conflicts with somebody else; I see there is such a ref.", which is the right thing to do. Otherwise a push to a hidden ref will always be "the last one wins", which is not a good default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 04:08:30 +04:00
# idempotent push to update a hidden ref should fail
test_must_fail git push testrepo $the_first_commit:refs/hidden/three &&
check_push_result testrepo $the_first_commit hidden/three
upload/receive-pack: allow hiding ref hierarchies A repository may have refs that are only used for its internal bookkeeping purposes that should not be exposed to the others that come over the network. Teach upload-pack to omit some refs from its initial advertisement by paying attention to the uploadpack.hiderefs multi-valued configuration variable. Do the same to receive-pack via the receive.hiderefs variable. As a convenient short-hand, allow using transfer.hiderefs to set the value to both of these variables. Any ref that is under the hierarchies listed on the value of these variable is excluded from responses to requests made by "ls-remote", "fetch", etc. (for upload-pack) and "push" (for receive-pack). Because these hidden refs do not count as OUR_REF, an attempt to fetch objects at the tip of them will be rejected, and because these refs do not get advertised, "git push :" will not see local branches that have the same name as them as "matching" ones to be sent. An attempt to update/delete these hidden refs with an explicit refspec, e.g. "git push origin :refs/hidden/22", is rejected. This is not a new restriction. To the pusher, it would appear that there is no such ref, so its push request will conclude with "Now that I sent you all the data, it is time for you to update the refs. I saw that the ref did not exist when I started pushing, and I want the result to point at this commit". The receiving end will apply the compare-and-swap rule to this request and rejects the push with "Well, your update request conflicts with somebody else; I see there is such a ref.", which is the right thing to do. Otherwise a push to a hidden ref will always be "the last one wins", which is not a good default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 04:08:30 +04:00
'
done
test_expect_success 'fetch exact SHA1' '
mk_test testrepo heads/main hidden/one &&
git push testrepo main:refs/hidden/one &&
(
cd testrepo &&
git config transfer.hiderefs refs/hidden
) &&
check_push_result testrepo $the_commit hidden/one &&
mk_child testrepo child &&
(
cd child &&
# make sure $the_commit does not exist here
git repack -a -d &&
git prune &&
test_must_fail git cat-file -t $the_commit &&
# Some protocol versions (e.g. 2) support fetching
# unadvertised objects, so restrict this test to v0.
# fetching the hidden object should fail by default
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 \
git fetch -v ../testrepo $the_commit:refs/heads/copy 2>err &&
test_i18ngrep "Server does not allow request for unadvertised object" err &&
test_must_fail git rev-parse --verify refs/heads/copy &&
# the server side can allow it to succeed
(
cd ../testrepo &&
git config uploadpack.allowtipsha1inwant true
) &&
git fetch -v ../testrepo $the_commit:refs/heads/copy main:refs/heads/extra &&
filter_ref: make a copy of extra "sought" entries If the server supports allow_tip_sha1_in_want, we add any unmatched raw-sha1 entries in our "sought" list of refs to the list of refs we will ask the other side for. We do so by inserting the original "struct ref" directly into our list, rather than making a copy. This has several problems. The most minor problem is that one cannot ever free the resulting list; it contains structs that are copies of the remote refs (made earlier by fetch_pack) along with sought refs that are referenced elsewhere. But more importantly that we set the ref->next pointer to NULL, chopping off the remainder of any existing list that the ref was a part of. We get the set of "sought" refs in an array rather than a linked list, but that array is often in turn generated from a list. The test modification in t5516 demonstrates this. Rather than fetching just an exact sha1, we fetch that sha1 plus another ref: - we build a linked list of refs to fetch when do_fetch calls get_ref_map; the exact sha1 is first, followed by the named ref ("refs/heads/extra" in this case). - we pass that linked list to transport_fetch_ref, which squashes it into an array of pointers - that array goes to fetch_pack, which calls filter_ref. There we generate the want list from a mix of what the remote side has advertised, and the "sought" entry for the exact sha1. We set the sought entry's "next" pointer to NULL. - after we return from transport_fetch_refs, we then try to update the refs by following the linked list. But our list is now truncated, and we do not update refs/heads/extra at all. We can fix this by making a copy of the ref. There's nothing that fetch_pack does to it that must be reflected in the original "sought" list (and indeed, if that were the case we would have a serious bug, because it is only exact-sha1 entries which are treated this way). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-19 23:37:09 +03:00
cat >expect <<-EOF &&
$the_commit
$the_first_commit
EOF
{
git rev-parse --verify refs/heads/copy &&
git rev-parse --verify refs/heads/extra
} >actual &&
test_cmp expect actual
)
'
fetch: do not pass ref-prefixes for fetch by exact SHA1 When v2.18.0-rc0~10^2~1 (refspec: consolidate ref-prefix generation logic, 2018-05-16) factored out the ref-prefix generation code for reuse, it left out the 'if (!item->exact_sha1)' test in the original ref-prefix generation code. As a result, fetches by SHA-1 generate ref-prefixes as though the SHA-1 being fetched were an abbreviated ref name: $ GIT_TRACE_PACKET=1 bin-wrappers/git -c protocol.version=2 \ fetch origin 12039e008f9a4e3394f3f94f8ea897785cb09448 [...] packet: fetch> ref-prefix 12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/tags/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/heads/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448/HEAD packet: fetch> 0000 If there is another ref name on the command line or the object being fetched is already available locally, then that's mostly harmless. But otherwise, we error out with fatal: no matching remote head since the server did not send any refs we are interested in. Filter out the exact_sha1 refspecs to avoid this. This patch adds a test to check this behavior that notices another behavior difference between protocol v0 and v2 in the process. Add a NEEDSWORK comment to clear it up. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-31 10:23:39 +03:00
test_expect_success 'fetch exact SHA1 in protocol v2' '
mk_test testrepo heads/main hidden/one &&
git push testrepo main:refs/hidden/one &&
fetch: do not pass ref-prefixes for fetch by exact SHA1 When v2.18.0-rc0~10^2~1 (refspec: consolidate ref-prefix generation logic, 2018-05-16) factored out the ref-prefix generation code for reuse, it left out the 'if (!item->exact_sha1)' test in the original ref-prefix generation code. As a result, fetches by SHA-1 generate ref-prefixes as though the SHA-1 being fetched were an abbreviated ref name: $ GIT_TRACE_PACKET=1 bin-wrappers/git -c protocol.version=2 \ fetch origin 12039e008f9a4e3394f3f94f8ea897785cb09448 [...] packet: fetch> ref-prefix 12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/tags/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/heads/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448/HEAD packet: fetch> 0000 If there is another ref name on the command line or the object being fetched is already available locally, then that's mostly harmless. But otherwise, we error out with fatal: no matching remote head since the server did not send any refs we are interested in. Filter out the exact_sha1 refspecs to avoid this. This patch adds a test to check this behavior that notices another behavior difference between protocol v0 and v2 in the process. Add a NEEDSWORK comment to clear it up. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-31 10:23:39 +03:00
git -C testrepo config transfer.hiderefs refs/hidden &&
check_push_result testrepo $the_commit hidden/one &&
mk_child testrepo child &&
git -C child config protocol.version 2 &&
# make sure $the_commit does not exist here
git -C child repack -a -d &&
git -C child prune &&
test_must_fail git -C child cat-file -t $the_commit &&
# fetching the hidden object succeeds by default
# NEEDSWORK: should this match the v0 behavior instead?
git -C child fetch -v ../testrepo $the_commit:refs/heads/copy
'
for configallowtipsha1inwant in true false
do
test_expect_success "shallow fetch reachable SHA1 (but not a ref), allowtipsha1inwant=$configallowtipsha1inwant" '
mk_empty testrepo &&
(
cd testrepo &&
git config uploadpack.allowtipsha1inwant $configallowtipsha1inwant &&
git commit --allow-empty -m foo &&
git commit --allow-empty -m bar
) &&
SHA1=$(git --git-dir=testrepo/.git rev-parse HEAD^) &&
mk_empty shallow &&
(
cd shallow &&
# Some protocol versions (e.g. 2) support fetching
# unadvertised objects, so restrict this test to v0.
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 \
git fetch --depth=1 ../testrepo/.git $SHA1 &&
git --git-dir=../testrepo/.git config uploadpack.allowreachablesha1inwant true &&
git fetch --depth=1 ../testrepo/.git $SHA1 &&
git cat-file commit $SHA1
)
'
test_expect_success "deny fetch unreachable SHA1, allowtipsha1inwant=$configallowtipsha1inwant" '
mk_empty testrepo &&
(
cd testrepo &&
git config uploadpack.allowtipsha1inwant $configallowtipsha1inwant &&
git commit --allow-empty -m foo &&
git commit --allow-empty -m bar &&
git commit --allow-empty -m xyz
) &&
SHA1_1=$(git --git-dir=testrepo/.git rev-parse HEAD^^) &&
SHA1_2=$(git --git-dir=testrepo/.git rev-parse HEAD^) &&
SHA1_3=$(git --git-dir=testrepo/.git rev-parse HEAD) &&
(
cd testrepo &&
git reset --hard $SHA1_2 &&
git cat-file commit $SHA1_1 &&
git cat-file commit $SHA1_3
) &&
mk_empty shallow &&
(
cd shallow &&
# Some protocol versions (e.g. 2) support fetching
# unadvertised objects, so restrict this test to v0.
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 \
git fetch ../testrepo/.git $SHA1_3 &&
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 \
git fetch ../testrepo/.git $SHA1_1 &&
git --git-dir=../testrepo/.git config uploadpack.allowreachablesha1inwant true &&
git fetch ../testrepo/.git $SHA1_1 &&
git cat-file commit $SHA1_1 &&
test_must_fail git cat-file commit $SHA1_2 &&
git fetch ../testrepo/.git $SHA1_2 &&
git cat-file commit $SHA1_2 &&
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 \
git fetch ../testrepo/.git $SHA1_3 2>err &&
t5516: loosen "not our ref" error check Commit 014ade7484 (upload-pack: send ERR packet for non-tip objects, 2019-04-13) added a test that greps the output of a failed fetch to make sure that upload-pack sent us the ERR packet we expected. But checking this is racy; despite the argument in that commit, the client may still be sending a "done" line after the server exits, causing it to die() on a failed write() and never see the ERR packet at all. This fails quite rarely on Linux, but more often on macOS. However, it can be triggered reliably with: diff --git a/fetch-pack.c b/fetch-pack.c index 876f90c759..cf40de9092 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -489,6 +489,7 @@ static int find_common(struct fetch_negotiator *negotiator, done: trace2_region_leave("fetch-pack", "negotiation_v0_v1", the_repository); if (!got_ready || !no_done) { + sleep(1); packet_buf_write(&req_buf, "done\n"); send_request(args, fd[1], &req_buf); } This is a real user-visible race that it would be nice to fix, but it's tricky to do so: the client would have to speculatively try to read an ERR packet after hitting a write() error. And at least for this error, it's specific to v0 (since v2 does not enforce reachability at all). So let's loosen the test to avoid annoying racy failures. If we eventually do the read-after-failed-write thing, we can tighten it. And if not, v0 will grow increasingly obsolete as servers support v2, so the utility of this test will decrease over time anyway. Note that we can still check stderr to make sure upload-pack bailed for the reason we expected. It writes a similar message to stderr, and because the server side is just another process connected by pipes, we'll reliably see it. This would not be the case for git://, or for ssh servers that do not relay stderr (e.g., GitHub's custom endpoint does not). Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-10 06:23:09 +03:00
# ideally we would insist this be on a "remote error:"
# line, but it is racy; see the commit message
test_i18ngrep "not our ref.*$SHA1_3\$" err
)
'
done
test_expect_success 'fetch follows tags by default' '
mk_test testrepo heads/main &&
rm -fr src dst &&
git init src &&
(
cd src &&
git pull ../testrepo main &&
git tag -m "annotated" tag &&
git for-each-ref >tmp1 &&
(
cat tmp1
sed -n "s|refs/heads/main$|refs/remotes/origin/main|p" tmp1
) |
sort -k 3 >../expect
) &&
git init dst &&
(
cd dst &&
git remote add origin ../src &&
git config branch.main.remote origin &&
git config branch.main.merge refs/heads/main &&
git pull &&
git for-each-ref >../actual
) &&
test_cmp expect actual
'
fetch: do not consider peeled tags as advertised tips Our filter_refs() function accidentally considers the target of a peeled tag to be advertised by the server, even though upload-pack on the server side does not consider it so. This can result in the client making a bogus fetch to the server, which will end with the server complaining "not our ref". Whereas the correct behavior is for the client to notice that the server will not allow the request and error out immediately. So as bugs go, this is not very serious (the outcome is the same either way -- the fetch fails). But it's worth making the logic here correct and consistent with other related cases (e.g., fetching an oid that the server did not mention at all). The crux of the issue comes from fdb69d33c4 (fetch-pack: always allow fetching of literal SHA1s, 2017-05-15). After that, the strategy of filter_refs() is basically: - for each advertised ref, try to match it with a "sought" ref provided by the user. Skip any malformed refs (which includes peeled values like "refs/tags/foo^{}"), and place any unmatched items onto the unmatched list. - if there are unmatched sought refs, then put all of the advertised tips into an oidset, including the unmatched ones. - for each sought ref, see if it's in the oidset, in which case it's legal for us to ask the server for it The problem is in the second step. Our list of unmatched refs includes the peeled refs, even though upload-pack does not allow them to be directly fetched. So the simplest fix would be to exclude them during that step. However, we can observe that the unmatched list isn't used for anything else, and is freed at the end. We can just free those malformed refs immediately. That saves us having to check each ref a second time to see if it's malformed. Note that this code only kicks in when "strict" is in effect. I.e., if we are using the v0 protocol and uploadpack.allowReachableSHA1InWant is not in effect. With v2, all oids are allowed, and we do not bother creating or consulting the oidset at all. To future-proof our test against the upcoming GIT_TEST_PROTOCOL_VERSION flag, we'll manually mark it as a v0-only test. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-13 08:57:37 +03:00
test_expect_success 'peeled advertisements are not considered ref tips' '
mk_empty testrepo &&
git -C testrepo commit --allow-empty -m one &&
git -C testrepo commit --allow-empty -m two &&
git -C testrepo tag -m foo mytag HEAD^ &&
oid=$(git -C testrepo rev-parse mytag^{commit}) &&
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 \
fetch: do not consider peeled tags as advertised tips Our filter_refs() function accidentally considers the target of a peeled tag to be advertised by the server, even though upload-pack on the server side does not consider it so. This can result in the client making a bogus fetch to the server, which will end with the server complaining "not our ref". Whereas the correct behavior is for the client to notice that the server will not allow the request and error out immediately. So as bugs go, this is not very serious (the outcome is the same either way -- the fetch fails). But it's worth making the logic here correct and consistent with other related cases (e.g., fetching an oid that the server did not mention at all). The crux of the issue comes from fdb69d33c4 (fetch-pack: always allow fetching of literal SHA1s, 2017-05-15). After that, the strategy of filter_refs() is basically: - for each advertised ref, try to match it with a "sought" ref provided by the user. Skip any malformed refs (which includes peeled values like "refs/tags/foo^{}"), and place any unmatched items onto the unmatched list. - if there are unmatched sought refs, then put all of the advertised tips into an oidset, including the unmatched ones. - for each sought ref, see if it's in the oidset, in which case it's legal for us to ask the server for it The problem is in the second step. Our list of unmatched refs includes the peeled refs, even though upload-pack does not allow them to be directly fetched. So the simplest fix would be to exclude them during that step. However, we can observe that the unmatched list isn't used for anything else, and is freed at the end. We can just free those malformed refs immediately. That saves us having to check each ref a second time to see if it's malformed. Note that this code only kicks in when "strict" is in effect. I.e., if we are using the v0 protocol and uploadpack.allowReachableSHA1InWant is not in effect. With v2, all oids are allowed, and we do not bother creating or consulting the oidset at all. To future-proof our test against the upcoming GIT_TEST_PROTOCOL_VERSION flag, we'll manually mark it as a v0-only test. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-13 08:57:37 +03:00
git fetch testrepo $oid 2>err &&
test_i18ngrep "Server does not allow request for unadvertised object" err
'
push: use remote.$name.push as a refmap Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 03:41:15 +04:00
test_expect_success 'pushing a specific ref applies remote.$name.push as refmap' '
mk_test testrepo heads/main &&
push: use remote.$name.push as a refmap Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 03:41:15 +04:00
rm -fr src dst &&
git init src &&
git init --bare dst &&
(
cd src &&
git pull ../testrepo main &&
push: use remote.$name.push as a refmap Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 03:41:15 +04:00
git branch next &&
git config remote.dst.url ../dst &&
git config remote.dst.push "+refs/heads/*:refs/remotes/src/*" &&
git push dst main &&
git show-ref refs/heads/main |
push: use remote.$name.push as a refmap Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 03:41:15 +04:00
sed -e "s|refs/heads/|refs/remotes/src/|" >../dst/expect
) &&
(
cd dst &&
test_must_fail git show-ref refs/heads/next &&
test_must_fail git show-ref refs/heads/main &&
git show-ref refs/remotes/src/main >actual
push: use remote.$name.push as a refmap Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 03:41:15 +04:00
) &&
test_cmp dst/expect dst/actual
'
test_expect_success 'with no remote.$name.push, it is not used as refmap' '
mk_test testrepo heads/main &&
push: use remote.$name.push as a refmap Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 03:41:15 +04:00
rm -fr src dst &&
git init src &&
git init --bare dst &&
(
cd src &&
git pull ../testrepo main &&
push: use remote.$name.push as a refmap Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 03:41:15 +04:00
git branch next &&
git config remote.dst.url ../dst &&
git config push.default matching &&
git push dst main &&
git show-ref refs/heads/main >../dst/expect
push: use remote.$name.push as a refmap Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 03:41:15 +04:00
) &&
(
cd dst &&
test_must_fail git show-ref refs/heads/next &&
git show-ref refs/heads/main >actual
push: use remote.$name.push as a refmap Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04 03:41:15 +04:00
) &&
test_cmp dst/expect dst/actual
'
test_expect_success 'with no remote.$name.push, upstream mapping is used' '
mk_test testrepo heads/main &&
rm -fr src dst &&
git init src &&
git init --bare dst &&
(
cd src &&
git pull ../testrepo main &&
git branch next &&
git config remote.dst.url ../dst &&
git config remote.dst.fetch "+refs/heads/*:refs/remotes/dst/*" &&
git config push.default upstream &&
git config branch.main.merge refs/heads/trunk &&
git config branch.main.remote dst &&
git push dst main &&
git show-ref refs/heads/main |
sed -e "s|refs/heads/main|refs/heads/trunk|" >../dst/expect
) &&
(
cd dst &&
test_must_fail git show-ref refs/heads/main &&
test_must_fail git show-ref refs/heads/next &&
git show-ref refs/heads/trunk >actual
) &&
test_cmp dst/expect dst/actual
'
test_expect_success 'push does not follow tags by default' '
mk_test testrepo heads/main &&
rm -fr src dst &&
git init src &&
git init --bare dst &&
(
cd src &&
git pull ../testrepo main &&
git tag -m "annotated" tag &&
git checkout -b another &&
git commit --allow-empty -m "future commit" &&
git tag -m "future" future &&
git checkout main &&
git for-each-ref refs/heads/main >../expect &&
git push ../dst main
) &&
(
cd dst &&
git for-each-ref >../actual
) &&
test_cmp expect actual
'
test_expect_success 'push --follow-tags only pushes relevant tags' '
mk_test testrepo heads/main &&
rm -fr src dst &&
git init src &&
git init --bare dst &&
(
cd src &&
git pull ../testrepo main &&
git tag -m "annotated" tag &&
git checkout -b another &&
git commit --allow-empty -m "future commit" &&
git tag -m "future" future &&
git checkout main &&
git for-each-ref refs/heads/main refs/tags/tag >../expect &&
git push --follow-tags ../dst main
) &&
(
cd dst &&
git for-each-ref >../actual
) &&
test_cmp expect actual
'
test_expect_success 'push --no-thin must produce non-thin pack' '
cat >>path1 <<\EOF &&
keep base version of path1 big enough, compared to the new changes
later, in order to pass size heuristics in
builtin/pack-objects.c:try_delta()
EOF
git commit -am initial &&
git init no-thin &&
git --git-dir=no-thin/.git config receive.unpacklimit 0 &&
git push no-thin/.git refs/heads/main:refs/heads/foo &&
echo modified >> path1 &&
git commit -am modified &&
git repack -adf &&
rcvpck="git receive-pack --reject-thin-pack-for-testing" &&
git push --no-thin --receive-pack="$rcvpck" no-thin/.git refs/heads/main:refs/heads/foo
'
test_expect_success 'pushing a tag pushes the tagged object' '
rm -rf dst.git &&
blob=$(echo unreferenced | git hash-object -w --stdin) &&
git tag -m foo tag-of-blob $blob &&
git init --bare dst.git &&
git push dst.git tag-of-blob &&
# the receiving index-pack should have noticed
# any problems, but we double check
echo unreferenced >expect &&
git --git-dir=dst.git cat-file blob tag-of-blob >actual &&
test_cmp expect actual
'
test_expect_success 'push into bare respects core.logallrefupdates' '
rm -rf dst.git &&
git init --bare dst.git &&
git -C dst.git config core.logallrefupdates true &&
# double push to test both with and without
# the actual pack transfer
git push dst.git main:one &&
echo "one@{0} push" >expect &&
git -C dst.git log -g --format="%gd %gs" one >actual &&
test_cmp expect actual &&
git push dst.git main:two &&
echo "two@{0} push" >expect &&
git -C dst.git log -g --format="%gd %gs" two >actual &&
test_cmp expect actual
'
test_expect_success 'fetch into bare respects core.logallrefupdates' '
rm -rf dst.git &&
git init --bare dst.git &&
(
cd dst.git &&
git config core.logallrefupdates true &&
# as above, we double-fetch to test both
# with and without pack transfer
git fetch .. main:one &&
echo "one@{0} fetch .. main:one: storing head" >expect &&
git log -g --format="%gd %gs" one >actual &&
test_cmp expect actual &&
git fetch .. main:two &&
echo "two@{0} fetch .. main:two: storing head" >expect &&
git log -g --format="%gd %gs" two >actual &&
test_cmp expect actual
)
'
test_expect_success 'receive.denyCurrentBranch = updateInstead' '
git push testrepo main &&
(
cd testrepo &&
git reset --hard &&
git config receive.denyCurrentBranch updateInstead
) &&
test_commit third path2 &&
# Try pushing into a repository with pristine working tree
git push testrepo main &&
(
cd testrepo &&
git update-index -q --refresh &&
git diff-files --quiet -- &&
git diff-index --quiet --cached HEAD -- &&
test third = "$(cat path2)" &&
test $(git -C .. rev-parse HEAD) = $(git rev-parse HEAD)
) &&
# Try pushing into a repository with working tree needing a refresh
(
cd testrepo &&
git reset --hard HEAD^ &&
test $(git -C .. rev-parse HEAD^) = $(git rev-parse HEAD) &&
test-tool chmtime +100 path1
) &&
git push testrepo main &&
(
cd testrepo &&
git update-index -q --refresh &&
git diff-files --quiet -- &&
git diff-index --quiet --cached HEAD -- &&
test_cmp ../path1 path1 &&
test third = "$(cat path2)" &&
test $(git -C .. rev-parse HEAD) = $(git rev-parse HEAD)
) &&
# Update what is to be pushed
test_commit fourth path2 &&
# Try pushing into a repository with a dirty working tree
# (1) the working tree updated
(
cd testrepo &&
echo changed >path1
) &&
test_must_fail git push testrepo main &&
(
cd testrepo &&
test $(git -C .. rev-parse HEAD^) = $(git rev-parse HEAD) &&
git diff --quiet --cached &&
test changed = "$(cat path1)"
) &&
# (2) the index updated
(
cd testrepo &&
echo changed >path1 &&
git add path1
) &&
test_must_fail git push testrepo main &&
(
cd testrepo &&
test $(git -C .. rev-parse HEAD^) = $(git rev-parse HEAD) &&
git diff --quiet &&
test changed = "$(cat path1)"
) &&
# Introduce a new file in the update
test_commit fifth path3 &&
# (3) the working tree has an untracked file that would interfere
(
cd testrepo &&
git reset --hard &&
echo changed >path3
) &&
test_must_fail git push testrepo main &&
(
cd testrepo &&
test $(git -C .. rev-parse HEAD^^) = $(git rev-parse HEAD) &&
git diff --quiet &&
git diff --quiet --cached &&
test changed = "$(cat path3)"
) &&
# (4) the target changes to what gets pushed but it still is a change
(
cd testrepo &&
git reset --hard &&
echo fifth >path3 &&
git add path3
) &&
test_must_fail git push testrepo main &&
(
cd testrepo &&
test $(git -C .. rev-parse HEAD^^) = $(git rev-parse HEAD) &&
git diff --quiet &&
test fifth = "$(cat path3)"
) &&
# (5) push into void
rm -fr void &&
git init void &&
(
cd void &&
git config receive.denyCurrentBranch updateInstead
) &&
git push void main &&
(
cd void &&
test $(git -C .. rev-parse main) = $(git rev-parse HEAD) &&
git diff --quiet &&
git diff --cached --quiet
) &&
# (6) updateInstead intervened by fast-forward check
test_must_fail git push void main^:main &&
test $(git -C void rev-parse HEAD) = $(git rev-parse main) &&
git -C void diff --quiet &&
git -C void diff --cached --quiet
'
test_expect_success 'updateInstead with push-to-checkout hook' '
rm -fr testrepo &&
git init testrepo &&
(
cd testrepo &&
git pull .. main &&
git reset --hard HEAD^^ &&
git tag initial &&
git config receive.denyCurrentBranch updateInstead &&
write_script .git/hooks/push-to-checkout <<-\EOF
echo >&2 updating from $(git rev-parse HEAD)
echo >&2 updating to "$1"
git update-index -q --refresh &&
git read-tree -u -m HEAD "$1" || {
status=$?
echo >&2 read-tree failed
exit $status
}
EOF
) &&
# Try pushing into a pristine
git push testrepo main &&
(
cd testrepo &&
git diff --quiet &&
git diff HEAD --quiet &&
test $(git -C .. rev-parse HEAD) = $(git rev-parse HEAD)
) &&
# Try pushing into a repository with conflicting change
(
cd testrepo &&
git reset --hard initial &&
echo conflicting >path2
) &&
test_must_fail git push testrepo main &&
(
cd testrepo &&
test $(git rev-parse initial) = $(git rev-parse HEAD) &&
test conflicting = "$(cat path2)" &&
git diff-index --quiet --cached HEAD
) &&
# Try pushing into a repository with unrelated change
(
cd testrepo &&
git reset --hard initial &&
echo unrelated >path1 &&
echo irrelevant >path5 &&
git add path5
) &&
git push testrepo main &&
(
cd testrepo &&
test "$(cat path1)" = unrelated &&
test "$(cat path5)" = irrelevant &&
test "$(git diff --name-only --cached HEAD)" = path5 &&
test $(git -C .. rev-parse HEAD) = $(git rev-parse HEAD)
) &&
# push into void
rm -fr void &&
git init void &&
(
cd void &&
git config receive.denyCurrentBranch updateInstead &&
write_script .git/hooks/push-to-checkout <<-\EOF
if git rev-parse --quiet --verify HEAD
then
has_head=yes
echo >&2 updating from $(git rev-parse HEAD)
else
has_head=no
echo >&2 pushing into void
fi
echo >&2 updating to "$1"
git update-index -q --refresh &&
case "$has_head" in
yes)
git read-tree -u -m HEAD "$1" ;;
no)
git read-tree -u -m "$1" ;;
esac || {
status=$?
echo >&2 read-tree failed
exit $status
}
EOF
) &&
git push void main &&
(
cd void &&
git diff --quiet &&
git diff --cached --quiet &&
test $(git -C .. rev-parse HEAD) = $(git rev-parse HEAD)
)
'
receive.denyCurrentBranch: respect all worktrees The receive.denyCurrentBranch config option controls what happens if you push to a branch that is checked out into a non-bare repository. By default, it rejects it. It can be disabled via `ignore` or `warn`. Another yet trickier option is `updateInstead`. However, this setting was forgotten when the git worktree command was introduced: only the main worktree's current branch is respected. With this change, all worktrees are respected. That change also leads to revealing another bug, i.e. `receive.denyCurrentBranch = true` was ignored when pushing into a non-bare repository's unborn current branch using ref namespaces. As `is_ref_checked_out()` returns 0 which means `receive-pack` does not get into conditional statement to switch `deny_current_branch` accordingly (ignore, warn, refuse, unconfigured, updateInstead). receive.denyCurrentBranch uses the function `refs_resolve_ref_unsafe()` (called via `resolve_refdup()`) to resolve the symbolic ref HEAD, but that function fails when HEAD does not point at a valid commit. As we replace the call to `refs_resolve_ref_unsafe()` with `find_shared_symref()`, which has no problem finding the worktree for a given branch even if it is unborn yet, this bug is fixed at the same time: receive.denyCurrentBranch now also handles worktrees with unborn branches as intended even while using ref namespaces. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-23 21:57:10 +03:00
test_expect_success 'denyCurrentBranch and worktrees' '
git worktree add new-wt &&
git clone . cloned &&
test_commit -C cloned first &&
test_config receive.denyCurrentBranch refuse &&
test_must_fail git -C cloned push origin HEAD:new-wt &&
test_config receive.denyCurrentBranch updateInstead &&
git -C cloned push origin HEAD:new-wt &&
test_must_fail git -C cloned push --delete origin new-wt
'
test_done