git/t/t5510-fetch.sh

689 lines
18 KiB
Bash
Raw Normal View History

#!/bin/sh
# Copyright (c) 2006, Junio C Hamano.
test_description='Per branch config variables affects "git fetch".
'
. ./test-lib.sh
D=$(pwd)
test_bundle_object_count () {
git verify-pack -v "$1" >verify.out &&
test "$2" = $(grep '^[0-9a-f]\{40\} ' verify.out | wc -l)
}
convert_bundle_to_pack () {
while read x && test -n "$x"
do
:;
done
cat
}
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"
) &&
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
) &&
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
) &&
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>
2008-06-17 00:15:02 +08:00
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 "$one_in_two "
echo "$master_in_two not-for-merge"
} >expected &&
cut -f -2 .git/FETCH_HEAD >actual &&
test_cmp expected actual'
test_expect_success 'fetch --prune on its own works as expected' '
cd "$D" &&
git clone . prune &&
cd prune &&
git update-ref refs/remotes/origin/extrabranch master &&
git fetch --prune origin &&
test_must_fail git rev-parse origin/extrabranch
'
test_expect_success 'fetch --prune with a branch name keeps branches' '
cd "$D" &&
git clone . prune-branch &&
cd prune-branch &&
git update-ref refs/remotes/origin/extrabranch master &&
git fetch --prune origin master &&
git rev-parse origin/extrabranch
'
test_expect_success 'fetch --prune with a namespace keeps other namespaces' '
cd "$D" &&
git clone . prune-namespace &&
cd prune-namespace &&
git fetch --prune origin refs/heads/a/*:refs/remotes/origin/a/* &&
git rev-parse origin/master
'
test_expect_success 'fetch --prune handles overlapping refspecs' '
cd "$D" &&
git update-ref refs/pull/42/head master &&
git clone . prune-overlapping &&
cd prune-overlapping &&
git config --add remote.origin.fetch refs/pull/*/head:refs/remotes/origin/pr/* &&
git fetch --prune origin &&
git rev-parse origin/master &&
git rev-parse origin/pr/42 &&
git config --unset-all remote.origin.fetch &&
git config remote.origin.fetch refs/pull/*/head:refs/remotes/origin/pr/* &&
git config --add remote.origin.fetch refs/heads/*:refs/remotes/origin/* &&
git fetch --prune origin &&
git rev-parse origin/master &&
git rev-parse origin/pr/42
'
fetch --prune: prune only based on explicit refspecs The old behavior of "fetch --prune" was to prune whatever was being fetched. In particular, "fetch --prune --tags" caused tags not only to be fetched, but also to be pruned. This is inappropriate because there is only one tags namespace that is shared among the local repository and all remotes. Therefore, if the user defines a local tag and then runs "git fetch --prune --tags", then the local tag is deleted. Moreover, "--prune" and "--tags" can also be configured via fetch.prune / remote.<name>.prune and remote.<name>.tagopt, making it even less obvious that an invocation of "git fetch" could result in tag lossage. Since the command "git remote update" invokes "git fetch", it had the same problem. The command "git remote prune", on the other hand, disregarded the setting of remote.<name>.tagopt, and so its behavior was inconsistent with that of the other commands. So the old behavior made it too easy to lose tags. To fix this problem, change "fetch --prune" to prune references based only on refspecs specified explicitly by the user, either on the command line or via remote.<name>.fetch. Thus, tags are no longer made subject to pruning by the --tags option or the remote.<name>.tagopt setting. However, tags *are* still subject to pruning if they are fetched as part of a refspec, and that is good. For example: * On the command line, git fetch --prune 'refs/tags/*:refs/tags/*' causes tags, and only tags, to be fetched and pruned, and is therefore a simple way for the user to get the equivalent of the old behavior of "--prune --tag". * For a remote that was configured with the "--mirror" option, the configuration is set to include [remote "name"] fetch = +refs/*:refs/* , which causes tags to be subject to pruning along with all other references. This is the behavior that will typically be desired for a mirror. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30 13:33:00 +08:00
test_expect_success 'fetch --prune --tags prunes branches but not tags' '
cd "$D" &&
git clone . prune-tags &&
cd prune-tags &&
git tag sometag master &&
# Create what looks like a remote-tracking branch from an earlier
# fetch that has since been deleted from the remote:
git update-ref refs/remotes/origin/fake-remote master &&
git fetch --prune --tags origin &&
git rev-parse origin/master &&
test_must_fail git rev-parse origin/fake-remote &&
fetch --prune: prune only based on explicit refspecs The old behavior of "fetch --prune" was to prune whatever was being fetched. In particular, "fetch --prune --tags" caused tags not only to be fetched, but also to be pruned. This is inappropriate because there is only one tags namespace that is shared among the local repository and all remotes. Therefore, if the user defines a local tag and then runs "git fetch --prune --tags", then the local tag is deleted. Moreover, "--prune" and "--tags" can also be configured via fetch.prune / remote.<name>.prune and remote.<name>.tagopt, making it even less obvious that an invocation of "git fetch" could result in tag lossage. Since the command "git remote update" invokes "git fetch", it had the same problem. The command "git remote prune", on the other hand, disregarded the setting of remote.<name>.tagopt, and so its behavior was inconsistent with that of the other commands. So the old behavior made it too easy to lose tags. To fix this problem, change "fetch --prune" to prune references based only on refspecs specified explicitly by the user, either on the command line or via remote.<name>.fetch. Thus, tags are no longer made subject to pruning by the --tags option or the remote.<name>.tagopt setting. However, tags *are* still subject to pruning if they are fetched as part of a refspec, and that is good. For example: * On the command line, git fetch --prune 'refs/tags/*:refs/tags/*' causes tags, and only tags, to be fetched and pruned, and is therefore a simple way for the user to get the equivalent of the old behavior of "--prune --tag". * For a remote that was configured with the "--mirror" option, the configuration is set to include [remote "name"] fetch = +refs/*:refs/* , which causes tags to be subject to pruning along with all other references. This is the behavior that will typically be desired for a mirror. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30 13:33:00 +08:00
git rev-parse sometag
'
fetch --prune: prune only based on explicit refspecs The old behavior of "fetch --prune" was to prune whatever was being fetched. In particular, "fetch --prune --tags" caused tags not only to be fetched, but also to be pruned. This is inappropriate because there is only one tags namespace that is shared among the local repository and all remotes. Therefore, if the user defines a local tag and then runs "git fetch --prune --tags", then the local tag is deleted. Moreover, "--prune" and "--tags" can also be configured via fetch.prune / remote.<name>.prune and remote.<name>.tagopt, making it even less obvious that an invocation of "git fetch" could result in tag lossage. Since the command "git remote update" invokes "git fetch", it had the same problem. The command "git remote prune", on the other hand, disregarded the setting of remote.<name>.tagopt, and so its behavior was inconsistent with that of the other commands. So the old behavior made it too easy to lose tags. To fix this problem, change "fetch --prune" to prune references based only on refspecs specified explicitly by the user, either on the command line or via remote.<name>.fetch. Thus, tags are no longer made subject to pruning by the --tags option or the remote.<name>.tagopt setting. However, tags *are* still subject to pruning if they are fetched as part of a refspec, and that is good. For example: * On the command line, git fetch --prune 'refs/tags/*:refs/tags/*' causes tags, and only tags, to be fetched and pruned, and is therefore a simple way for the user to get the equivalent of the old behavior of "--prune --tag". * For a remote that was configured with the "--mirror" option, the configuration is set to include [remote "name"] fetch = +refs/*:refs/* , which causes tags to be subject to pruning along with all other references. This is the behavior that will typically be desired for a mirror. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30 13:33:00 +08:00
test_expect_success 'fetch --prune --tags with branch does not prune other things' '
cd "$D" &&
git clone . prune-tags-branch &&
cd prune-tags-branch &&
git tag sometag master &&
git update-ref refs/remotes/origin/extrabranch master &&
git fetch --prune --tags origin master &&
git rev-parse origin/extrabranch &&
fetch --prune: prune only based on explicit refspecs The old behavior of "fetch --prune" was to prune whatever was being fetched. In particular, "fetch --prune --tags" caused tags not only to be fetched, but also to be pruned. This is inappropriate because there is only one tags namespace that is shared among the local repository and all remotes. Therefore, if the user defines a local tag and then runs "git fetch --prune --tags", then the local tag is deleted. Moreover, "--prune" and "--tags" can also be configured via fetch.prune / remote.<name>.prune and remote.<name>.tagopt, making it even less obvious that an invocation of "git fetch" could result in tag lossage. Since the command "git remote update" invokes "git fetch", it had the same problem. The command "git remote prune", on the other hand, disregarded the setting of remote.<name>.tagopt, and so its behavior was inconsistent with that of the other commands. So the old behavior made it too easy to lose tags. To fix this problem, change "fetch --prune" to prune references based only on refspecs specified explicitly by the user, either on the command line or via remote.<name>.fetch. Thus, tags are no longer made subject to pruning by the --tags option or the remote.<name>.tagopt setting. However, tags *are* still subject to pruning if they are fetched as part of a refspec, and that is good. For example: * On the command line, git fetch --prune 'refs/tags/*:refs/tags/*' causes tags, and only tags, to be fetched and pruned, and is therefore a simple way for the user to get the equivalent of the old behavior of "--prune --tag". * For a remote that was configured with the "--mirror" option, the configuration is set to include [remote "name"] fetch = +refs/*:refs/* , which causes tags to be subject to pruning along with all other references. This is the behavior that will typically be desired for a mirror. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30 13:33:00 +08:00
git rev-parse sometag
'
test_expect_success 'fetch --prune --tags with refspec prunes based on refspec' '
cd "$D" &&
git clone . prune-tags-refspec &&
cd prune-tags-refspec &&
git tag sometag master &&
git update-ref refs/remotes/origin/foo/otherbranch master &&
git update-ref refs/remotes/origin/extrabranch master &&
git fetch --prune --tags origin refs/heads/foo/*:refs/remotes/origin/foo/* &&
test_must_fail git rev-parse refs/remotes/origin/foo/otherbranch &&
git rev-parse origin/extrabranch &&
fetch --prune: prune only based on explicit refspecs The old behavior of "fetch --prune" was to prune whatever was being fetched. In particular, "fetch --prune --tags" caused tags not only to be fetched, but also to be pruned. This is inappropriate because there is only one tags namespace that is shared among the local repository and all remotes. Therefore, if the user defines a local tag and then runs "git fetch --prune --tags", then the local tag is deleted. Moreover, "--prune" and "--tags" can also be configured via fetch.prune / remote.<name>.prune and remote.<name>.tagopt, making it even less obvious that an invocation of "git fetch" could result in tag lossage. Since the command "git remote update" invokes "git fetch", it had the same problem. The command "git remote prune", on the other hand, disregarded the setting of remote.<name>.tagopt, and so its behavior was inconsistent with that of the other commands. So the old behavior made it too easy to lose tags. To fix this problem, change "fetch --prune" to prune references based only on refspecs specified explicitly by the user, either on the command line or via remote.<name>.fetch. Thus, tags are no longer made subject to pruning by the --tags option or the remote.<name>.tagopt setting. However, tags *are* still subject to pruning if they are fetched as part of a refspec, and that is good. For example: * On the command line, git fetch --prune 'refs/tags/*:refs/tags/*' causes tags, and only tags, to be fetched and pruned, and is therefore a simple way for the user to get the equivalent of the old behavior of "--prune --tag". * For a remote that was configured with the "--mirror" option, the configuration is set to include [remote "name"] fetch = +refs/*:refs/* , which causes tags to be subject to pruning along with all other references. This is the behavior that will typically be desired for a mirror. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30 13:33:00 +08:00
git rev-parse sometag
'
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
'
test_expect_success 'fetch uses remote ref names to describe new refs' '
cd "$D" &&
git init descriptive &&
(
cd descriptive &&
git config remote.o.url .. &&
git config remote.o.fetch "refs/heads/*:refs/crazyheads/*" &&
git config --add remote.o.fetch "refs/others/*:refs/heads/*" &&
git fetch o
) &&
git tag -a -m "Descriptive tag" descriptive-tag &&
git branch descriptive-branch &&
git checkout descriptive-branch &&
echo "Nuts" >crazy &&
git add crazy &&
git commit -a -m "descriptive commit" &&
git update-ref refs/others/crazy HEAD &&
(
cd descriptive &&
git fetch o 2>actual &&
grep " -> refs/crazyheads/descriptive-branch$" actual |
test_i18ngrep "new branch" &&
grep " -> descriptive-tag$" actual |
test_i18ngrep "new tag" &&
grep " -> crazy$" actual |
test_i18ngrep "new ref"
) &&
git checkout 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>
2008-02-01 17:50:53 +08:00
test_expect_success 'fetch must not resolve short tag name' '
2007-11-11 22:01:48 +08:00
cd "$D" &&
mkdir five &&
cd five &&
git init &&
test_must_fail git fetch .. anno:five
2007-11-11 22:01:48 +08:00
'
test_expect_success 'fetch can now resolve short remote name' '
2007-11-11 22:01:48 +08:00
cd "$D" &&
git update-ref refs/remotes/six/HEAD HEAD &&
2007-11-11 22:01:48 +08:00
mkdir six &&
cd six &&
git init &&
git fetch .. six:six
2007-11-11 22:01:48 +08:00
'
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>
2008-02-01 17:50:53 +08:00
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" &&
convert_bundle_to_pack <bundle1 >bundle.pack &&
git index-pack bundle.pack &&
test_bundle_object_count bundle.pack 3
'
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 &&
convert_bundle_to_pack <bundle3 >bundle.pack &&
git index-pack bundle.pack &&
test_bundle_object_count bundle.pack 3
'
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_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
'
# URL supplied to fetch does not match the url of the configured branch's remote
test_expect_success 'fetch from GIT URL with a non-applying branch.<name>.merge [1]' '
one_head=$(cd one && git rev-parse HEAD) &&
this_head=$(git rev-parse HEAD) &&
git update-ref -d FETCH_HEAD &&
git fetch one &&
test $one_head = "$(git rev-parse --verify FETCH_HEAD)" &&
test $this_head = "$(git rev-parse --verify HEAD)"
'
# URL supplied to fetch matches the url of the configured branch's remote and
# the merge spec matches the branch the remote HEAD points to
test_expect_success 'fetch from GIT URL with a non-applying branch.<name>.merge [2]' '
one_ref=$(cd one && git symbolic-ref HEAD) &&
git config branch.master.remote blub &&
git config branch.master.merge "$one_ref" &&
git update-ref -d FETCH_HEAD &&
git fetch one &&
test $one_head = "$(git rev-parse --verify FETCH_HEAD)" &&
test $this_head = "$(git rev-parse --verify HEAD)"
'
# URL supplied to fetch matches the url of the configured branch's remote, but
# the merge spec does not match the branch the remote HEAD points to
test_expect_success 'fetch from GIT URL with a non-applying branch.<name>.merge [3]' '
git config branch.master.merge "${one_ref}_not" &&
git update-ref -d FETCH_HEAD &&
git fetch one &&
test $one_head = "$(git rev-parse --verify FETCH_HEAD)" &&
test $this_head = "$(git rev-parse --verify HEAD)"
'
# 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 'mark initial state of origin/master' '
(
cd three &&
git tag base-origin-master refs/remotes/origin/master
)
'
test_expect_success 'explicit fetch should update tracking' '
cd "$D" &&
git branch -f side &&
(
cd three &&
git update-ref refs/remotes/origin/master base-origin-master &&
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 update tracking' '
cd "$D" &&
git branch -f side &&
(
cd three &&
git update-ref refs/remotes/origin/master base-origin-master &&
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 'explicit --refmap is allowed only with command-line refspec' '
cd "$D" &&
(
cd three &&
test_must_fail git fetch --refmap="*:refs/remotes/none/*"
)
'
test_expect_success 'explicit --refmap option overrides remote.*.fetch' '
cd "$D" &&
git branch -f side &&
(
cd three &&
git update-ref refs/remotes/origin/master base-origin-master &&
o=$(git rev-parse --verify refs/remotes/origin/master) &&
git fetch --refmap="refs/heads/*:refs/remotes/other/*" 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 &&
git rev-parse --verify refs/remotes/other/master
)
'
test_expect_success 'explicitly empty --refmap option disables remote.*.fetch' '
cd "$D" &&
git branch -f side &&
(
cd three &&
git update-ref refs/remotes/origin/master base-origin-master &&
o=$(git rev-parse --verify refs/remotes/origin/master) &&
git fetch --refmap="" 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 &&
git update-ref refs/remotes/origin/master base-origin-master &&
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
)
'
test_expect_success 'non-matching refspecs do not confuse tracking update' '
cd "$D" &&
git update-ref refs/odd/location HEAD &&
(
cd three &&
git update-ref refs/remotes/origin/master base-origin-master &&
git config --add remote.origin.fetch \
refs/odd/location:refs/remotes/origin/odd &&
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/odd
)
'
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>
2008-06-17 00:15:02 +08:00
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_expect_success 'fetch --dry-run' '
rm -f .git/FETCH_HEAD &&
git fetch --dry-run . &&
! test -f .git/FETCH_HEAD
'
test_expect_success "should be able to fetch with duplicate refspecs" '
mkdir dups &&
(
cd dups &&
git init &&
git config branch.master.remote three &&
git config remote.three.url ../three/.git &&
git config remote.three.fetch +refs/heads/*:refs/remotes/origin/* &&
git config --add remote.three.fetch +refs/heads/*:refs/remotes/origin/* &&
git fetch three
)
'
# configured prune tests
set_config_tristate () {
# var=$1 val=$2
case "$2" in
unset) test_unconfig "$1" ;;
*) git config "$1" "$2" ;;
esac
}
test_configured_prune () {
fetch_prune=$1 remote_origin_prune=$2 cmdline=$3 expected=$4
test_expect_success "prune fetch.prune=$1 remote.origin.prune=$2${3:+ $3}; $4" '
# make sure a newbranch is there in . and also in one
git branch -f newbranch &&
(
cd one &&
test_unconfig fetch.prune &&
test_unconfig remote.origin.prune &&
git fetch &&
git rev-parse --verify refs/remotes/origin/newbranch
) &&
# now remove it
git branch -d newbranch &&
# then test
(
cd one &&
set_config_tristate fetch.prune $fetch_prune &&
set_config_tristate remote.origin.prune $remote_origin_prune &&
git fetch $cmdline &&
case "$expected" in
pruned)
test_must_fail git rev-parse --verify refs/remotes/origin/newbranch
;;
kept)
git rev-parse --verify refs/remotes/origin/newbranch
;;
esac
)
'
}
test_configured_prune unset unset "" kept
test_configured_prune unset unset "--no-prune" kept
test_configured_prune unset unset "--prune" pruned
test_configured_prune false unset "" kept
test_configured_prune false unset "--no-prune" kept
test_configured_prune false unset "--prune" pruned
test_configured_prune true unset "" pruned
test_configured_prune true unset "--prune" pruned
test_configured_prune true unset "--no-prune" kept
test_configured_prune unset false "" kept
test_configured_prune unset false "--no-prune" kept
test_configured_prune unset false "--prune" pruned
test_configured_prune false false "" kept
test_configured_prune false false "--no-prune" kept
test_configured_prune false false "--prune" pruned
test_configured_prune true false "" kept
test_configured_prune true false "--prune" pruned
test_configured_prune true false "--no-prune" kept
test_configured_prune unset true "" pruned
test_configured_prune unset true "--no-prune" kept
test_configured_prune unset true "--prune" pruned
test_configured_prune false true "" pruned
test_configured_prune false true "--no-prune" kept
test_configured_prune false true "--prune" pruned
test_configured_prune true true "" pruned
test_configured_prune true true "--prune" pruned
test_configured_prune true true "--no-prune" kept
test_expect_success 'all boundary commits are excluded' '
test_commit base &&
test_commit oneside &&
git checkout HEAD^ &&
test_commit otherside &&
git checkout master &&
test_tick &&
git merge otherside &&
ad=$(git log --no-walk --format=%ad HEAD) &&
git bundle create twoside-boundary.bdl master --since="$ad" &&
convert_bundle_to_pack <twoside-boundary.bdl >twoside-boundary.pack &&
pack=$(git index-pack --fix-thin --stdin <twoside-boundary.pack) &&
test_bundle_object_count .git/objects/pack/pack-${pack##pack }.pack 3
'
test_expect_success 'fetch --prune prints the remotes url' '
git branch goodbye &&
git clone . only-prunes &&
git branch -D goodbye &&
(
cd only-prunes &&
git fetch --prune origin 2>&1 | head -n1 >../actual
) &&
echo "From ${D}/." >expect &&
test_cmp expect actual
'
test_expect_success 'branchname D/F conflict resolved by --prune' '
git branch dir/file &&
git clone . prune-df-conflict &&
git branch -D dir/file &&
git branch dir &&
(
cd prune-df-conflict &&
git fetch --prune &&
git rev-parse origin/dir >../actual
) &&
git rev-parse dir >expect &&
test_cmp expect actual
'
fetch-pack: do not filter out one-level refs Currently fetching a one-level ref like "refs/foo" does not work consistently. The outer "git fetch" program filters the list of refs, checking each against check_refname_format. Then it feeds the result to do_fetch_pack to actually negotiate the haves/wants and get the pack. The fetch-pack code does its own filter, and it behaves differently. The fetch-pack filter looks for refs in "refs/", and then feeds everything _after_ the slash (i.e., just "foo") into check_refname_format. But check_refname_format is not designed to look at a partial refname. It complains that the ref has only one component, thinking it is at the root (i.e., alongside "HEAD"), when in reality we just fed it a partial refname. As a result, we omit a ref like "refs/foo" from the pack request, even though "git fetch" then tries to store the resulting ref. If we happen to get the object anyway (e.g., because the ref is contained in another ref we are fetching), then the fetch succeeds. But if it is a unique object, we fail when trying to update "refs/foo". We can fix this by just passing the whole refname into check_refname_format; we know the part we were omitting is "refs/", which is acceptable in a refname. This at least makes the checks consistent with each other. This problem happens most commonly with "refs/stash", which is the only one-level ref in wide use. However, our test does not use "refs/stash", as we may later want to restrict it specifically (not because it is one-level, but because of the semantics of stashes). We may also want to do away with the multiple levels of filtering (which can cause problems when they are out of sync), or even forbid one-level refs entirely. However, those decisions can come later; this fixes the most immediate problem, which is the mismatch between the two. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 18:46:13 +08:00
test_expect_success 'fetching a one-level ref works' '
test_commit extra &&
git reset --hard HEAD^ &&
git update-ref refs/foo extra &&
git init one-level &&
(
cd one-level &&
git fetch .. HEAD refs/foo
)
'
test_expect_success 'fetching with auto-gc does not lock up' '
write_script askyesno <<-\EOF &&
echo "$*" &&
false
EOF
git clone "file://$D" auto-gc &&
test_commit test2 &&
cd auto-gc &&
git config gc.autoPackLimit 1 &&
GIT_ASK_YESNO="$D/askyesno" git fetch >fetch.out 2>&1 &&
! grep "Should I try again" fetch.out
'
test_done