You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

339 lines
7.2 KiB

#!/bin/sh
# Copyright (c) 2006, Junio C Hamano.
test_description='Per branch config variables affects "git fetch".
'
. ./test-lib.sh
D=`pwd`
test_expect_success setup '
echo >file original &&
git add file &&
git commit -a -m original'
test_expect_success "clone and setup child repos" '
git clone . one &&
cd one &&
echo >file updated by one &&
git commit -a -m "updated by one" &&
cd .. &&
git clone . two &&
cd two &&
git config branch.master.remote one &&
git config remote.one.url ../one/.git/ &&
git config remote.one.fetch refs/heads/master:refs/heads/one &&
cd .. &&
git clone . three &&
cd three &&
git config branch.master.remote two &&
git config branch.master.merge refs/heads/one &&
mkdir -p .git/remotes &&
{
echo "URL: ../two/.git/"
echo "Pull: refs/heads/master:refs/heads/two"
echo "Pull: refs/heads/one:refs/heads/one"
} >.git/remotes/two &&
cd .. &&
clean up error conventions of remote.c:match_explicit match_explicit is called for each push refspec to try to fully resolve the source and destination sides of the refspec. Currently, we look at each refspec and report errors on both the source and the dest side before aborting. It makes sense to report errors for each refspec, since an error in one is independent of an error in the other. However, reporting errors on the 'dst' side of a refspec if there has been an error on the 'src' side does not necessarily make sense, since the interpretation of the 'dst' side depends on the 'src' side (for example, when creating a new unqualified remote ref, we use the same type as the src ref). This patch lets match_explicit return early when the src side of the refspec is bogus. We still look at all of the refspecs before aborting the push, though. At the same time, we clean up the call signature, which previously took an extra "errs" flag. This was pointless, as we didn't act on that flag, but rather just passed it back to the caller. Instead, we now use the more traditional "return -1" to signal an error, and the caller aggregates the error count. This change fixes two bugs, as well: - the early return avoids a segfault when passing a NULL matched_src to guess_ref() - the check for multiple sources pointing to a single dest aborted if the "err" flag was set. Presumably the intent was not to bother with the check if we had no matched_src. However, since the err flag was passed in from the caller, we might abort the check just because a previous refspec had a problem, which doesn't make sense. In practice, this didn't matter, since due to the error flag we end up aborting the push anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
git clone . bundle &&
git clone . seven
'
test_expect_success "fetch test" '
cd "$D" &&
echo >file updated by origin &&
git commit -a -m "updated by origin" &&
cd two &&
git fetch &&
test -f .git/refs/heads/one &&
mine=`git rev-parse refs/heads/one` &&
his=`cd ../one && git rev-parse refs/heads/master` &&
test "z$mine" = "z$his"
'
test_expect_success "fetch test for-merge" '
cd "$D" &&
cd three &&
git fetch &&
test -f .git/refs/heads/two &&
test -f .git/refs/heads/one &&
master_in_two=`cd ../two && git rev-parse master` &&
one_in_two=`cd ../two && git rev-parse one` &&
{
echo "$master_in_two not-for-merge"
echo "$one_in_two "
} >expected &&
cut -f -2 .git/FETCH_HEAD >actual &&
diff expected actual'
test_expect_success 'fetch tags when there is no tags' '
cd "$D" &&
mkdir notags &&
cd notags &&
git init &&
git fetch -t ..
'
test_expect_success 'fetch following tags' '
cd "$D" &&
git tag -a -m 'annotated' anno HEAD &&
git tag light HEAD &&
mkdir four &&
cd four &&
git init &&
git fetch .. :track &&
git show-ref --verify refs/tags/anno &&
git show-ref --verify refs/tags/light
'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
test_expect_success 'fetch must not resolve short tag name' '
cd "$D" &&
mkdir five &&
cd five &&
git init &&
test_must_fail git fetch .. anno:five
'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
test_expect_success 'fetch must not resolve short remote name' '
cd "$D" &&
git update-ref refs/remotes/six/HEAD HEAD
mkdir six &&
cd six &&
git init &&
test_must_fail git fetch .. six:six
'
test_expect_success 'create bundle 1' '
cd "$D" &&
echo >file updated again by origin &&
git commit -a -m "tip" &&
git bundle create bundle1 master^..master
'
test_expect_success 'header of bundle looks right' '
head -n 1 "$D"/bundle1 | grep "^#" &&
head -n 2 "$D"/bundle1 | grep "^-[0-9a-f]\{40\} " &&
head -n 3 "$D"/bundle1 | grep "^[0-9a-f]\{40\} " &&
head -n 4 "$D"/bundle1 | grep "^$"
'
test_expect_success 'create bundle 2' '
cd "$D" &&
git bundle create bundle2 master~2..master
'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
test_expect_success 'unbundle 1' '
cd "$D/bundle" &&
git checkout -b some-branch &&
test_must_fail git fetch "$D/bundle1" master:master
'
test_expect_success 'bundle 1 has only 3 files ' '
cd "$D" &&
(
while read x && test -n "$x"
do
:;
done
cat
) <bundle1 >bundle.pack &&
git index-pack bundle.pack &&
verify=$(git verify-pack -v bundle.pack) &&
test 4 = $(echo "$verify" | wc -l)
'
test_expect_success 'unbundle 2' '
cd "$D/bundle" &&
git fetch ../bundle2 master:master &&
test "tip" = "$(git log -1 --pretty=oneline master | cut -b42-)"
'
test_expect_success 'bundle does not prerequisite objects' '
cd "$D" &&
touch file2 &&
git add file2 &&
git commit -m add.file2 file2 &&
git bundle create bundle3 -1 HEAD &&
(
while read x && test -n "$x"
do
:;
done
cat
) <bundle3 >bundle.pack &&
git index-pack bundle.pack &&
test 4 = $(git verify-pack -v bundle.pack | wc -l)
'
test_expect_success 'bundle should be able to create a full history' '
cd "$D" &&
git tag -a -m '1.0' v1.0 master &&
git bundle create bundle4 v1.0
'
test "$TEST_RSYNC" && {
test_expect_success 'fetch via rsync' '
git pack-refs &&
mkdir rsynced &&
cd rsynced &&
git init &&
git fetch rsync://127.0.0.1$(pwd)/../.git master:refs/heads/master &&
git gc --prune &&
test $(git rev-parse master) = $(cd .. && git rev-parse master) &&
git fsck --full
'
test_expect_success 'push via rsync' '
mkdir ../rsynced2 &&
(cd ../rsynced2 &&
git init) &&
git push rsync://127.0.0.1$(pwd)/../rsynced2/.git master &&
cd ../rsynced2 &&
git gc --prune &&
test $(git rev-parse master) = $(cd .. && git rev-parse master) &&
git fsck --full
'
test_expect_success 'push via rsync' '
cd .. &&
mkdir rsynced3 &&
(cd rsynced3 &&
git init) &&
git push --all rsync://127.0.0.1$(pwd)/rsynced3/.git &&
cd rsynced3 &&
test $(git rev-parse master) = $(cd .. && git rev-parse master) &&
git fsck --full
'
}
test_expect_success 'fetch with a non-applying branch.<name>.merge' '
git config branch.master.remote yeti &&
git config branch.master.merge refs/heads/bigfoot &&
git config remote.blub.url one &&
git config remote.blub.fetch "refs/heads/*:refs/remotes/one/*" &&
git fetch blub
'
# the strange name is: a\!'b
test_expect_success 'quoting of a strangely named repo' '
test_must_fail git fetch "a\\!'\''b" > result 2>&1 &&
cat result &&
grep "fatal: '\''a\\\\!'\''b'\''" result
'
test_expect_success 'bundle should record HEAD correctly' '
cd "$D" &&
git bundle create bundle5 HEAD master &&
git bundle list-heads bundle5 >actual &&
for h in HEAD refs/heads/master
do
echo "$(git rev-parse --verify $h) $h"
done >expect &&
test_cmp expect actual
'
test_expect_success 'explicit fetch should not update tracking' '
cd "$D" &&
git branch -f side &&
(
cd three &&
o=$(git rev-parse --verify refs/remotes/origin/master) &&
git fetch origin master &&
n=$(git rev-parse --verify refs/remotes/origin/master) &&
test "$o" = "$n" &&
test_must_fail git rev-parse --verify refs/remotes/origin/side
)
'
test_expect_success 'explicit pull should not update tracking' '
cd "$D" &&
git branch -f side &&
(
cd three &&
o=$(git rev-parse --verify refs/remotes/origin/master) &&
git pull origin master &&
n=$(git rev-parse --verify refs/remotes/origin/master) &&
test "$o" = "$n" &&
test_must_fail git rev-parse --verify refs/remotes/origin/side
)
'
test_expect_success 'configured fetch updates tracking' '
cd "$D" &&
git branch -f side &&
(
cd three &&
o=$(git rev-parse --verify refs/remotes/origin/master) &&
git fetch origin &&
n=$(git rev-parse --verify refs/remotes/origin/master) &&
test "$o" != "$n" &&
git rev-parse --verify refs/remotes/origin/side
)
'
clean up error conventions of remote.c:match_explicit match_explicit is called for each push refspec to try to fully resolve the source and destination sides of the refspec. Currently, we look at each refspec and report errors on both the source and the dest side before aborting. It makes sense to report errors for each refspec, since an error in one is independent of an error in the other. However, reporting errors on the 'dst' side of a refspec if there has been an error on the 'src' side does not necessarily make sense, since the interpretation of the 'dst' side depends on the 'src' side (for example, when creating a new unqualified remote ref, we use the same type as the src ref). This patch lets match_explicit return early when the src side of the refspec is bogus. We still look at all of the refspecs before aborting the push, though. At the same time, we clean up the call signature, which previously took an extra "errs" flag. This was pointless, as we didn't act on that flag, but rather just passed it back to the caller. Instead, we now use the more traditional "return -1" to signal an error, and the caller aggregates the error count. This change fixes two bugs, as well: - the early return avoids a segfault when passing a NULL matched_src to guess_ref() - the check for multiple sources pointing to a single dest aborted if the "err" flag was set. Presumably the intent was not to bother with the check if we had no matched_src. However, since the err flag was passed in from the caller, we might abort the check just because a previous refspec had a problem, which doesn't make sense. In practice, this didn't matter, since due to the error flag we end up aborting the push anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
test_expect_success 'pushing nonexistent branch by mistake should not segv' '
cd "$D" &&
test_must_fail git push seven no:no
'
test_expect_success 'auto tag following fetches minimum' '
cd "$D" &&
git clone .git follow &&
git checkout HEAD^0 &&
(
for i in 1 2 3 4 5 6 7
do
echo $i >>file &&
git commit -m $i -a &&
git tag -a -m $i excess-$i || exit 1
done
) &&
git checkout master &&
(
cd follow &&
git fetch
)
'
test_expect_success 'refuse to fetch into the current branch' '
test_must_fail git fetch . side:master
'
test_expect_success 'fetch into the current branch with --update-head-ok' '
git fetch --update-head-ok . side:master
'
test_done