git/t/t5505-remote.sh

1496 lines
40 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='git remote porcelain-ish'
. ./test-lib.sh
setup_repository () {
mkdir "$1" && (
cd "$1" &&
git init -b main &&
>file &&
git add file &&
test_tick &&
git commit -m "Initial" &&
git checkout -b side &&
>elif &&
git add elif &&
test_tick &&
git commit -m "Second" &&
git checkout main
)
}
tokens_match () {
echo "$1" | tr ' ' '\012' | sort | sed -e '/^$/d' >expect &&
echo "$2" | tr ' ' '\012' | sort | sed -e '/^$/d' >actual &&
test_cmp expect actual
}
check_remote_track () {
builtin-remote: new show output style The existing output of "git remote show <remote>" is too verbose for the information it provides. This patch teaches it to provide more information in less space. The output for push refspecs is addressed in the next patch. Before the patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branch merged with 'git pull' while on branch master master Remote branch merged with 'git pull' while on branch next next Remote branches merged with 'git pull' while on branch octopus foo bar baz frotz New remote branch (next fetch will store in remotes/origin) html Stale tracking branch (use 'git remote prune') bogus Tracked remote branches maint man master next pu todo After this patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branches: bogus stale (use 'git remote prune' to remove) html new (next fetch will store in remotes/origin) maint tracked man tracked master tracked next tracked pu tracked todo tracked Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz $ git remote show origin -n * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: (not queried) Remote branches: (status not queried) bogus maint man master next pu todo Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:27 +00:00
actual=$(git remote show "$1" | sed -ne 's|^ \(.*\) tracked$|\1|p')
shift &&
tokens_match "$*" "$actual"
}
check_tracking_branch () {
f="" &&
r=$(git for-each-ref "--format=%(refname)" |
sed -ne "s|^refs/remotes/$1/||p") &&
shift &&
tokens_match "$*" "$r"
}
test_expect_success setup '
setup_repository one &&
setup_repository two &&
(
cd two &&
git branch another
) &&
git clone one test
'
test_expect_success 'add remote whose URL agrees with url.<...>.insteadOf' '
test_config url.git@host.com:team/repo.git.insteadOf myremote &&
git remote add myremote git@host.com:team/repo.git
'
test_expect_success 'remote information for the origin' '
(
cd test &&
tokens_match origin "$(git remote)" &&
check_remote_track origin main side &&
check_tracking_branch origin HEAD main side
)
'
test_expect_success 'add another remote' '
(
cd test &&
git remote add -f second ../two &&
tokens_match "origin second" "$(git remote)" &&
check_tracking_branch second main side another &&
git for-each-ref "--format=%(refname)" refs/remotes |
sed -e "/^refs\/remotes\/origin\//d" \
-e "/^refs\/remotes\/second\//d" >actual &&
test_must_be_empty actual
)
'
test_expect_success 'setup bare clone for server' '
git clone --bare "file://$(pwd)/one" srv.bare &&
git -C srv.bare config --local uploadpack.allowfilter 1 &&
git -C srv.bare config --local uploadpack.allowanysha1inwant 1
'
test_expect_success 'filters for promisor remotes are listed by git remote -v' '
test_when_finished "rm -rf pc" &&
git clone --filter=blob:none "file://$(pwd)/srv.bare" pc &&
git -C pc remote -v >out &&
grep "srv.bare (fetch) \[blob:none\]" out &&
git -C pc config remote.origin.partialCloneFilter object:type=commit &&
git -C pc remote -v >out &&
grep "srv.bare (fetch) \[object:type=commit\]" out
'
test_expect_success 'filters should not be listed for non promisor remotes (remote -v)' '
test_when_finished "rm -rf pc" &&
git clone one pc &&
git -C pc remote -v >out &&
! grep "(fetch) \[.*\]" out
'
test_expect_success 'filters are listed by git remote -v only' '
test_when_finished "rm -rf pc" &&
git clone --filter=blob:none "file://$(pwd)/srv.bare" pc &&
git -C pc remote >out &&
! grep "\[blob:none\]" out &&
git -C pc remote show >out &&
! grep "\[blob:none\]" out
'
test_expect_success 'check remote-tracking' '
(
cd test &&
check_remote_track origin main side &&
check_remote_track second main side another
)
'
test_expect_success 'remote forces tracking branches' '
(
cd test &&
case $(git config remote.second.fetch) in
+*) true ;;
*) false ;;
esac
)
'
test_expect_success 'remove remote' '
(
cd test &&
git symbolic-ref refs/remotes/second/HEAD refs/remotes/second/main &&
git remote rm second
)
'
test_expect_success 'remove remote' '
(
cd test &&
tokens_match origin "$(git remote)" &&
check_remote_track origin main side &&
git for-each-ref "--format=%(refname)" refs/remotes |
sed -e "/^refs\/remotes\/origin\//d" >actual &&
test_must_be_empty actual
)
'
test_expect_success 'remove remote protects local branches' '
(
cd test &&
cat >expect1 <<-\EOF &&
Note: A branch outside the refs/remotes/ hierarchy was not removed;
to delete it, use:
git branch -d main
EOF
cat >expect2 <<-\EOF &&
Note: Some branches outside the refs/remotes/ hierarchy were not removed;
to delete them, use:
git branch -d foobranch
git branch -d main
EOF
git tag footag &&
git config --add remote.oops.fetch "+refs/*:refs/*" &&
git remote remove oops 2>actual1 &&
git branch foobranch &&
git config --add remote.oops.fetch "+refs/*:refs/*" &&
git remote rm oops 2>actual2 &&
git branch -d foobranch &&
git tag -d footag &&
test_cmp expect1 actual1 &&
test_cmp expect2 actual2
)
'
test_expect_success 'remove errors out early when deleting non-existent branch' '
(
cd test &&
remote: add meaningful exit code on missing/existing Change the exit code for the likes of "git remote add/rename" to exit with 2 if the remote in question doesn't exist, and 3 if it does. Before we'd just die() and exit with the general 128 exit code. This changes the output message from e.g.: fatal: remote origin already exists. To: error: remote origin already exists. Which I believe is a feature, since we generally use "fatal" for the generic errors, and "error" for the more specific ones with a custom exit code, but this part of the change may break code that already relies on stderr parsing (not that we ever supported that...). The motivation for this is a discussion around some code in GitLab's gitaly which wanted to check this, and had to parse stderr to do so: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2695 It's worth noting as an aside that a method of checking this that doesn't rely on that is to check with "git config" whether the value in question does or doesn't exist. That introduces a TOCTOU race condition, but on the other hand this code (e.g. "git remote add") already has a TOCTOU race. We go through the config.lock for the actual setting of the config, but the pseudocode logic is: read_config(); check_config_and_arg_sanity(); save_config(); So e.g. if a sleep() is added right after the remote_is_configured() check in add() we'll clobber remote.NAME.url, and add another (usually duplicate) remote.NAME.fetch entry (and other values, depending on invocation). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27 09:41:36 +00:00
echo "error: No such remote: '\''foo'\''" >expect &&
test_expect_code 2 git remote rm foo 2>actual &&
test_cmp expect actual
)
'
test_expect_success 'remove remote with a branch without configured merge' '
test_when_finished "(
git -C test checkout main;
git -C test branch -D two;
git -C test config --remove-section remote.two;
git -C test config --remove-section branch.second;
true
)" &&
(
cd test &&
git remote add two ../two &&
git fetch two &&
git checkout -b second two/main^0 &&
git config branch.second.remote two &&
git checkout main &&
git remote rm two
)
'
test_expect_success 'rename errors out early when deleting non-existent branch' '
(
cd test &&
remote: add meaningful exit code on missing/existing Change the exit code for the likes of "git remote add/rename" to exit with 2 if the remote in question doesn't exist, and 3 if it does. Before we'd just die() and exit with the general 128 exit code. This changes the output message from e.g.: fatal: remote origin already exists. To: error: remote origin already exists. Which I believe is a feature, since we generally use "fatal" for the generic errors, and "error" for the more specific ones with a custom exit code, but this part of the change may break code that already relies on stderr parsing (not that we ever supported that...). The motivation for this is a discussion around some code in GitLab's gitaly which wanted to check this, and had to parse stderr to do so: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2695 It's worth noting as an aside that a method of checking this that doesn't rely on that is to check with "git config" whether the value in question does or doesn't exist. That introduces a TOCTOU race condition, but on the other hand this code (e.g. "git remote add") already has a TOCTOU race. We go through the config.lock for the actual setting of the config, but the pseudocode logic is: read_config(); check_config_and_arg_sanity(); save_config(); So e.g. if a sleep() is added right after the remote_is_configured() check in add() we'll clobber remote.NAME.url, and add another (usually duplicate) remote.NAME.fetch entry (and other values, depending on invocation). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27 09:41:36 +00:00
echo "error: No such remote: '\''foo'\''" >expect &&
test_expect_code 2 git remote rename foo bar 2>actual &&
test_cmp expect actual
)
'
test_expect_success 'rename errors out early when new name is invalid' '
test_config remote.foo.vcs bar &&
echo "fatal: '\''invalid...name'\'' is not a valid remote name" >expect &&
test_must_fail git remote rename foo invalid...name 2>actual &&
test_cmp expect actual
'
test_expect_success 'add existing foreign_vcs remote' '
test_config remote.foo.vcs bar &&
remote: add meaningful exit code on missing/existing Change the exit code for the likes of "git remote add/rename" to exit with 2 if the remote in question doesn't exist, and 3 if it does. Before we'd just die() and exit with the general 128 exit code. This changes the output message from e.g.: fatal: remote origin already exists. To: error: remote origin already exists. Which I believe is a feature, since we generally use "fatal" for the generic errors, and "error" for the more specific ones with a custom exit code, but this part of the change may break code that already relies on stderr parsing (not that we ever supported that...). The motivation for this is a discussion around some code in GitLab's gitaly which wanted to check this, and had to parse stderr to do so: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2695 It's worth noting as an aside that a method of checking this that doesn't rely on that is to check with "git config" whether the value in question does or doesn't exist. That introduces a TOCTOU race condition, but on the other hand this code (e.g. "git remote add") already has a TOCTOU race. We go through the config.lock for the actual setting of the config, but the pseudocode logic is: read_config(); check_config_and_arg_sanity(); save_config(); So e.g. if a sleep() is added right after the remote_is_configured() check in add() we'll clobber remote.NAME.url, and add another (usually duplicate) remote.NAME.fetch entry (and other values, depending on invocation). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27 09:41:36 +00:00
echo "error: remote foo already exists." >expect &&
test_expect_code 3 git remote add foo bar 2>actual &&
test_cmp expect actual
'
test_expect_success 'add existing foreign_vcs remote' '
test_config remote.foo.vcs bar &&
test_config remote.bar.vcs bar &&
remote: add meaningful exit code on missing/existing Change the exit code for the likes of "git remote add/rename" to exit with 2 if the remote in question doesn't exist, and 3 if it does. Before we'd just die() and exit with the general 128 exit code. This changes the output message from e.g.: fatal: remote origin already exists. To: error: remote origin already exists. Which I believe is a feature, since we generally use "fatal" for the generic errors, and "error" for the more specific ones with a custom exit code, but this part of the change may break code that already relies on stderr parsing (not that we ever supported that...). The motivation for this is a discussion around some code in GitLab's gitaly which wanted to check this, and had to parse stderr to do so: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2695 It's worth noting as an aside that a method of checking this that doesn't rely on that is to check with "git config" whether the value in question does or doesn't exist. That introduces a TOCTOU race condition, but on the other hand this code (e.g. "git remote add") already has a TOCTOU race. We go through the config.lock for the actual setting of the config, but the pseudocode logic is: read_config(); check_config_and_arg_sanity(); save_config(); So e.g. if a sleep() is added right after the remote_is_configured() check in add() we'll clobber remote.NAME.url, and add another (usually duplicate) remote.NAME.fetch entry (and other values, depending on invocation). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27 09:41:36 +00:00
echo "error: remote bar already exists." >expect &&
test_expect_code 3 git remote rename foo bar 2>actual &&
test_cmp expect actual
'
test_expect_success 'add invalid foreign_vcs remote' '
echo "fatal: '\''invalid...name'\'' is not a valid remote name" >expect &&
test_must_fail git remote add invalid...name bar 2>actual &&
test_cmp expect actual
'
test_expect_success 'without subcommand' '
echo origin >expect &&
git -C test remote >actual &&
test_cmp expect actual
'
test_expect_success 'without subcommand accepts -v' '
cat >expect <<-EOF &&
origin $(pwd)/one (fetch)
origin $(pwd)/one (push)
EOF
git -C test remote -v >actual &&
test_cmp expect actual
'
test_expect_success 'without subcommand does not take arguments' '
test_expect_code 129 git -C test remote origin 2>err &&
grep "^error: unknown subcommand:" err
'
cat >test/expect <<EOF
* remote origin
Fetch URL: $(pwd)/one
Push URL: $(pwd)/one
HEAD branch: main
builtin-remote: new show output style The existing output of "git remote show <remote>" is too verbose for the information it provides. This patch teaches it to provide more information in less space. The output for push refspecs is addressed in the next patch. Before the patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branch merged with 'git pull' while on branch master master Remote branch merged with 'git pull' while on branch next next Remote branches merged with 'git pull' while on branch octopus foo bar baz frotz New remote branch (next fetch will store in remotes/origin) html Stale tracking branch (use 'git remote prune') bogus Tracked remote branches maint man master next pu todo After this patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branches: bogus stale (use 'git remote prune' to remove) html new (next fetch will store in remotes/origin) maint tracked man tracked master tracked next tracked pu tracked todo tracked Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz $ git remote show origin -n * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: (not queried) Remote branches: (status not queried) bogus maint man master next pu todo Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:27 +00:00
Remote branches:
main new (next fetch will store in remotes/origin)
side tracked
builtin-remote: new show output style The existing output of "git remote show <remote>" is too verbose for the information it provides. This patch teaches it to provide more information in less space. The output for push refspecs is addressed in the next patch. Before the patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branch merged with 'git pull' while on branch master master Remote branch merged with 'git pull' while on branch next next Remote branches merged with 'git pull' while on branch octopus foo bar baz frotz New remote branch (next fetch will store in remotes/origin) html Stale tracking branch (use 'git remote prune') bogus Tracked remote branches maint man master next pu todo After this patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branches: bogus stale (use 'git remote prune' to remove) html new (next fetch will store in remotes/origin) maint tracked man tracked master tracked next tracked pu tracked todo tracked Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz $ git remote show origin -n * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: (not queried) Remote branches: (status not queried) bogus maint man master next pu todo Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:27 +00:00
Local branches configured for 'git pull':
ahead merges with remote main
main merges with remote main
builtin-remote: new show output style The existing output of "git remote show <remote>" is too verbose for the information it provides. This patch teaches it to provide more information in less space. The output for push refspecs is addressed in the next patch. Before the patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branch merged with 'git pull' while on branch master master Remote branch merged with 'git pull' while on branch next next Remote branches merged with 'git pull' while on branch octopus foo bar baz frotz New remote branch (next fetch will store in remotes/origin) html Stale tracking branch (use 'git remote prune') bogus Tracked remote branches maint man master next pu todo After this patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branches: bogus stale (use 'git remote prune' to remove) html new (next fetch will store in remotes/origin) maint tracked man tracked master tracked next tracked pu tracked todo tracked Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz $ git remote show origin -n * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: (not queried) Remote branches: (status not queried) bogus maint man master next pu todo Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:27 +00:00
octopus merges with remote topic-a
and with remote topic-b
and with remote topic-c
rebase rebases onto remote main
builtin-remote: new show output style for push refspecs The existing output of "git remote show <remote>" with respect to push ref specs is basically just to show the raw refspec. This patch teaches the command to interpret the refspecs and show how each branch will be pushed to the destination. The output gives the user an idea of what "git push" should do if it is run w/o any arguments. Example new output: 1a. Typical output with no push refspec (i.e. matching branches only) $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (up to date) next pushes to next (local out of date) 1b. Same as above, w/o querying the remote: $ git remote show origin -n * remote origin [...] Local ref configured for 'git push' (status not queried): (matching) pushes to (matching) 2a. With a forcing refspec (+), and a new topic (something like push = refs/heads/*:refs/heads/*): $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (fast forwardable) new-topic pushes to new-topic (create) next pushes to next (local out of date) pu forces to pu (up to date) 2b. Same as above, w/o querying the remote $ git remote show origin -n * remote origin [...] Local refs configured for 'git push' (status not queried): master pushes to master new-topic pushes to new-topic next pushes to next pu forces to pu 3. With a remote configured as a mirror: * remote backup [...] Local refs will be mirrored by 'git push' Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:28 +00:00
Local refs configured for 'git push':
main pushes to main (local out of date)
main pushes to upstream (create)
* remote two
Fetch URL: ../two
Push URL: ../three
HEAD branch: main
builtin-remote: new show output style for push refspecs The existing output of "git remote show <remote>" with respect to push ref specs is basically just to show the raw refspec. This patch teaches the command to interpret the refspecs and show how each branch will be pushed to the destination. The output gives the user an idea of what "git push" should do if it is run w/o any arguments. Example new output: 1a. Typical output with no push refspec (i.e. matching branches only) $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (up to date) next pushes to next (local out of date) 1b. Same as above, w/o querying the remote: $ git remote show origin -n * remote origin [...] Local ref configured for 'git push' (status not queried): (matching) pushes to (matching) 2a. With a forcing refspec (+), and a new topic (something like push = refs/heads/*:refs/heads/*): $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (fast forwardable) new-topic pushes to new-topic (create) next pushes to next (local out of date) pu forces to pu (up to date) 2b. Same as above, w/o querying the remote $ git remote show origin -n * remote origin [...] Local refs configured for 'git push' (status not queried): master pushes to master new-topic pushes to new-topic next pushes to next pu forces to pu 3. With a remote configured as a mirror: * remote backup [...] Local refs will be mirrored by 'git push' Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:28 +00:00
Local refs configured for 'git push':
ahead forces to main (fast-forwardable)
main pushes to another (up to date)
EOF
test_expect_success 'show' '
(
cd test &&
git config --add remote.origin.fetch refs/heads/main:refs/heads/upstream &&
git fetch &&
git checkout -b ahead origin/main &&
echo 1 >>file &&
test_tick &&
git commit -m update file &&
git checkout main &&
git branch --track octopus origin/main &&
git branch --track rebase origin/main &&
git branch -d -r origin/main &&
git config --add remote.two.url ../two &&
git config --add remote.two.pushurl ../three &&
git config branch.rebase.rebase true &&
git config branch.octopus.merge "topic-a topic-b topic-c" &&
(
cd ../one &&
echo 1 >file &&
test_tick &&
git commit -m update file
) &&
git config --add remote.origin.push : &&
git config --add remote.origin.push refs/heads/main:refs/heads/upstream &&
git config --add remote.origin.push +refs/tags/lastbackup &&
git config --add remote.two.push +refs/heads/ahead:refs/heads/main &&
git config --add remote.two.push refs/heads/main:refs/heads/another &&
git remote show origin two >output &&
git branch -d rebase octopus &&
test_cmp expect output
)
'
remote: handle negative refspecs in git remote show By default, the git remote show command will query data from remotes to show data about what might be done on a future git fetch. This process currently does not handle negative refspecs. This can be confusing, because the show command will list refs as if they would be fetched. For example if the fetch refspec "^refs/heads/pr/*", it still displays the following: * remote jdk19 Fetch URL: git@github.com:openjdk/jdk19.git Push URL: git@github.com:openjdk/jdk19.git HEAD branch: master Remote branches: master tracked pr/1 new (next fetch will store in remotes/jdk19) pr/2 new (next fetch will store in remotes/jdk19) pr/3 new (next fetch will store in remotes/jdk19) Local ref configured for 'git push': master pushes to master (fast-forwardable) Fix this by adding an additional check inside of get_ref_states. If a ref matches one of the negative refspecs, mark it as skipped instead of marking it as new or tracked. With this change, we now report remote branches that are skipped due to negative refspecs properly: * remote jdk19 Fetch URL: git@github.com:openjdk/jdk19.git Push URL: git@github.com:openjdk/jdk19.git HEAD branch: master Remote branches: master tracked pr/1 skipped pr/2 skipped pr/3 skipped Local ref configured for 'git push': master pushes to master (fast-forwardable) By showing the refs as skipped, it helps clarify that these references won't actually be fetched. This does not properly handle refs going stale due to a newly added negative refspec. In addition, git remote prune doesn't handle that negative refspec case either. Fixing that requires digging into get_stale_heads and handling the case of a ref which exists on the remote but is omitted due to a negative refspec locally. Add a new test case which covers the functionality above, as well as a new expected failure indicating the poor overlap with stale refs. Reported-by: Pavel Rappo <pavel.rappo@gmail.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-17 00:20:31 +00:00
cat >expect <<EOF
* remote origin
Fetch URL: $(pwd)/one
Push URL: $(pwd)/one
HEAD branch: main
Remote branches:
main skipped
side tracked
Local branches configured for 'git pull':
ahead merges with remote main
main merges with remote main
Local refs configured for 'git push':
main pushes to main (local out of date)
main pushes to upstream (create)
EOF
test_expect_success 'show with negative refspecs' '
test_when_finished "git -C test config --unset-all --fixed-value remote.origin.fetch ^refs/heads/main" &&
git -C test config --add remote.origin.fetch ^refs/heads/main &&
git -C test remote show origin >output &&
test_cmp expect output
'
cat >expect <<EOF
* remote origin
Fetch URL: $(pwd)/one
Push URL: $(pwd)/one
HEAD branch: main
Remote branches:
main new (next fetch will store in remotes/origin)
side stale (use 'git remote prune' to remove)
Local branches configured for 'git pull':
ahead merges with remote main
main merges with remote main
Local refs configured for 'git push':
main pushes to main (local out of date)
main pushes to upstream (create)
EOF
test_expect_failure 'show stale with negative refspecs' '
test_when_finished "git -C test config --unset-all --fixed-value remote.origin.fetch ^refs/heads/side" &&
git -C test config --add remote.origin.fetch ^refs/heads/side &&
git -C test remote show origin >output &&
test_cmp expect output
'
cat >test/expect <<EOF
* remote origin
Fetch URL: $(pwd)/one
Push URL: $(pwd)/one
HEAD branch: (not queried)
builtin-remote: new show output style The existing output of "git remote show <remote>" is too verbose for the information it provides. This patch teaches it to provide more information in less space. The output for push refspecs is addressed in the next patch. Before the patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branch merged with 'git pull' while on branch master master Remote branch merged with 'git pull' while on branch next next Remote branches merged with 'git pull' while on branch octopus foo bar baz frotz New remote branch (next fetch will store in remotes/origin) html Stale tracking branch (use 'git remote prune') bogus Tracked remote branches maint man master next pu todo After this patch: $ git remote show origin * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branches: bogus stale (use 'git remote prune' to remove) html new (next fetch will store in remotes/origin) maint tracked man tracked master tracked next tracked pu tracked todo tracked Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz $ git remote show origin -n * remote origin URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: (not queried) Remote branches: (status not queried) bogus maint man master next pu todo Local branches configured for 'git pull': master rebases onto remote master next rebases onto remote next octopus merges with remote foo and with remote bar and with remote baz and with remote frotz Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:27 +00:00
Remote branches: (status not queried)
main
side
builtin-remote: new show output style for push refspecs The existing output of "git remote show <remote>" with respect to push ref specs is basically just to show the raw refspec. This patch teaches the command to interpret the refspecs and show how each branch will be pushed to the destination. The output gives the user an idea of what "git push" should do if it is run w/o any arguments. Example new output: 1a. Typical output with no push refspec (i.e. matching branches only) $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (up to date) next pushes to next (local out of date) 1b. Same as above, w/o querying the remote: $ git remote show origin -n * remote origin [...] Local ref configured for 'git push' (status not queried): (matching) pushes to (matching) 2a. With a forcing refspec (+), and a new topic (something like push = refs/heads/*:refs/heads/*): $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (fast forwardable) new-topic pushes to new-topic (create) next pushes to next (local out of date) pu forces to pu (up to date) 2b. Same as above, w/o querying the remote $ git remote show origin -n * remote origin [...] Local refs configured for 'git push' (status not queried): master pushes to master new-topic pushes to new-topic next pushes to next pu forces to pu 3. With a remote configured as a mirror: * remote backup [...] Local refs will be mirrored by 'git push' Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:28 +00:00
Local branches configured for 'git pull':
ahead merges with remote main
main merges with remote main
builtin-remote: new show output style for push refspecs The existing output of "git remote show <remote>" with respect to push ref specs is basically just to show the raw refspec. This patch teaches the command to interpret the refspecs and show how each branch will be pushed to the destination. The output gives the user an idea of what "git push" should do if it is run w/o any arguments. Example new output: 1a. Typical output with no push refspec (i.e. matching branches only) $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (up to date) next pushes to next (local out of date) 1b. Same as above, w/o querying the remote: $ git remote show origin -n * remote origin [...] Local ref configured for 'git push' (status not queried): (matching) pushes to (matching) 2a. With a forcing refspec (+), and a new topic (something like push = refs/heads/*:refs/heads/*): $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (fast forwardable) new-topic pushes to new-topic (create) next pushes to next (local out of date) pu forces to pu (up to date) 2b. Same as above, w/o querying the remote $ git remote show origin -n * remote origin [...] Local refs configured for 'git push' (status not queried): master pushes to master new-topic pushes to new-topic next pushes to next pu forces to pu 3. With a remote configured as a mirror: * remote backup [...] Local refs will be mirrored by 'git push' Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:28 +00:00
Local refs configured for 'git push' (status not queried):
(matching) pushes to (matching)
refs/heads/main pushes to refs/heads/upstream
builtin-remote: new show output style for push refspecs The existing output of "git remote show <remote>" with respect to push ref specs is basically just to show the raw refspec. This patch teaches the command to interpret the refspecs and show how each branch will be pushed to the destination. The output gives the user an idea of what "git push" should do if it is run w/o any arguments. Example new output: 1a. Typical output with no push refspec (i.e. matching branches only) $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (up to date) next pushes to next (local out of date) 1b. Same as above, w/o querying the remote: $ git remote show origin -n * remote origin [...] Local ref configured for 'git push' (status not queried): (matching) pushes to (matching) 2a. With a forcing refspec (+), and a new topic (something like push = refs/heads/*:refs/heads/*): $ git remote show origin * remote origin [...] Local refs configured for 'git push': master pushes to master (fast forwardable) new-topic pushes to new-topic (create) next pushes to next (local out of date) pu forces to pu (up to date) 2b. Same as above, w/o querying the remote $ git remote show origin -n * remote origin [...] Local refs configured for 'git push' (status not queried): master pushes to master new-topic pushes to new-topic next pushes to next pu forces to pu 3. With a remote configured as a mirror: * remote backup [...] Local refs will be mirrored by 'git push' Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 08:32:28 +00:00
refs/tags/lastbackup forces to refs/tags/lastbackup
EOF
test_expect_success 'show -n' '
mv one one.unreachable &&
(
cd test &&
git remote show -n origin >output &&
mv ../one.unreachable ../one &&
test_cmp expect output
)
'
test_expect_success 'prune' '
(
cd one &&
git branch -m side side2
) &&
(
cd test &&
git fetch origin &&
git remote prune origin &&
git rev-parse refs/remotes/origin/side2 &&
test_must_fail git rev-parse refs/remotes/origin/side
)
'
test_expect_success 'set-head --delete' '
(
cd test &&
git symbolic-ref refs/remotes/origin/HEAD &&
git remote set-head --delete origin &&
test_must_fail git symbolic-ref refs/remotes/origin/HEAD
)
'
test_expect_success 'set-head --auto' '
(
cd test &&
git remote set-head --auto origin &&
echo refs/remotes/origin/main >expect &&
git symbolic-ref refs/remotes/origin/HEAD >output &&
test_cmp expect output
)
'
test_expect_success 'set-head --auto has no problem w/multiple HEADs' '
(
cd test &&
git fetch two "refs/heads/*:refs/remotes/two/*" &&
git remote set-head --auto two >output 2>&1 &&
echo "two/HEAD set to main" >expect &&
test_cmp expect output
)
'
cat >test/expect <<\EOF
refs/remotes/origin/side2
EOF
test_expect_success 'set-head explicit' '
(
cd test &&
git remote set-head origin side2 &&
git symbolic-ref refs/remotes/origin/HEAD >output &&
git remote set-head origin main &&
test_cmp expect output
)
'
cat >test/expect <<EOF
Pruning origin
URL: $(pwd)/one
* [would prune] origin/side2
EOF
test_expect_success 'prune --dry-run' '
git -C one branch -m side2 side &&
test_when_finished "git -C one branch -m side side2" &&
(
cd test &&
git remote prune --dry-run origin >output &&
git rev-parse refs/remotes/origin/side2 &&
test_must_fail git rev-parse refs/remotes/origin/side &&
test_cmp expect output
)
'
test_expect_success 'add --mirror && prune' '
mkdir mirror &&
(
cd mirror &&
git init --bare &&
git remote add --mirror -f origin ../one
) &&
(
cd one &&
git branch -m side2 side
) &&
(
cd mirror &&
git rev-parse --verify refs/heads/side2 &&
test_must_fail git rev-parse --verify refs/heads/side &&
git fetch origin &&
git remote prune origin &&
test_must_fail git rev-parse --verify refs/heads/side2 &&
git rev-parse --verify refs/heads/side
)
'
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
test_expect_success 'add --mirror=fetch' '
mkdir mirror-fetch &&
git init -b main mirror-fetch/parent &&
(
cd mirror-fetch/parent &&
test_commit one
) &&
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
git init --bare mirror-fetch/child &&
(
cd mirror-fetch/child &&
git remote add --mirror=fetch -f parent ../parent
)
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
'
test_expect_success 'fetch mirrors act as mirrors during fetch' '
(
cd mirror-fetch/parent &&
git branch new &&
git branch -m main renamed
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
) &&
(
cd mirror-fetch/child &&
git fetch parent &&
git rev-parse --verify refs/heads/new &&
git rev-parse --verify refs/heads/renamed
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
)
'
test_expect_success 'fetch mirrors can prune' '
(
cd mirror-fetch/child &&
git remote prune parent &&
test_must_fail git rev-parse --verify refs/heads/main
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
)
'
test_expect_success 'fetch mirrors do not act as mirrors during push' '
(
cd mirror-fetch/parent &&
git checkout HEAD^0
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
) &&
(
cd mirror-fetch/child &&
git branch -m renamed renamed2 &&
git push parent :
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
) &&
(
cd mirror-fetch/parent &&
git rev-parse --verify renamed &&
test_must_fail git rev-parse --verify refs/heads/renamed2
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
)
'
test_expect_success 'add fetch mirror with specific branches' '
git init --bare mirror-fetch/track &&
(
cd mirror-fetch/track &&
git remote add --mirror=fetch -t heads/new parent ../parent
)
'
test_expect_success 'fetch mirror respects specific branches' '
(
cd mirror-fetch/track &&
git fetch parent &&
git rev-parse --verify refs/heads/new &&
test_must_fail git rev-parse --verify refs/heads/renamed
)
'
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
test_expect_success 'add --mirror=push' '
mkdir mirror-push &&
git init --bare mirror-push/public &&
git init -b main mirror-push/private &&
(
cd mirror-push/private &&
test_commit one &&
git remote add --mirror=push public ../public
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
)
'
test_expect_success 'push mirrors act as mirrors during push' '
(
cd mirror-push/private &&
git branch new &&
git branch -m main renamed &&
git push public
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
) &&
(
cd mirror-push/private &&
git rev-parse --verify refs/heads/new &&
git rev-parse --verify refs/heads/renamed &&
test_must_fail git rev-parse --verify refs/heads/main
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
)
'
test_expect_success 'push mirrors do not act as mirrors during fetch' '
(
cd mirror-push/public &&
git branch -m renamed renamed2 &&
git symbolic-ref HEAD refs/heads/renamed2
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
) &&
(
cd mirror-push/private &&
git fetch public &&
git rev-parse --verify refs/heads/renamed &&
test_must_fail git rev-parse --verify refs/heads/renamed2
remote: separate the concept of push and fetch mirrors git-remote currently has one option, "--mirror", which sets up mirror configuration which can be used for either fetching or pushing. It looks like this: [remote "mirror"] url = wherever fetch = +refs/*:refs/* mirror = true However, a remote like this can be dangerous and confusing. Specifically: 1. If you issue the wrong command, it can be devastating. You are not likely to "push" when you meant to "fetch", but "git remote update" will try to fetch it, even if you intended the remote only for pushing. In either case, the results can be quite destructive. An unintended push will overwrite or delete remote refs, and an unintended fetch can overwrite local branches. 2. The tracking setup code can produce confusing results. The fetch refspec above means that "git checkout -b new master" will consider refs/heads/master to come from the remote "mirror", even if you only ever intend to push to the mirror. It will set up the "new" branch to track mirror's refs/heads/master. 3. The push code tries to opportunistically update tracking branches. If you "git push mirror foo:bar", it will see that we are updating mirror's refs/heads/bar, which corresponds to our local refs/heads/bar, and will update our local branch. To solve this, we split the concept into "push mirrors" and "fetch mirrors". Push mirrors set only remote.*.mirror, solving (2) and (3), and making an accidental fetch write only into FETCH_HEAD. Fetch mirrors set only the fetch refspec, meaning an accidental push will not force-overwrite or delete refs on the remote end. The new syntax is "--mirror=<fetch|push>". For compatibility, we keep "--mirror" as-is, setting up both types simultaneously. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 19:53:19 +00:00
)
'
test_expect_success 'push mirrors do not allow you to specify refs' '
git init mirror-push/track &&
(
cd mirror-push/track &&
test_must_fail git remote add --mirror=push -t new public ../public
)
'
test_expect_success 'add alt && prune' '
mkdir alttst &&
(
cd alttst &&
git init &&
git remote add -f origin ../one &&
git config remote.alt.url ../one &&
git config remote.alt.fetch "+refs/heads/*:refs/remotes/origin/*"
) &&
(
cd one &&
git branch -m side side2
) &&
(
cd alttst &&
git rev-parse --verify refs/remotes/origin/side &&
test_must_fail git rev-parse --verify refs/remotes/origin/side2 &&
git fetch alt &&
git remote prune alt &&
test_must_fail git rev-parse --verify refs/remotes/origin/side &&
git rev-parse --verify refs/remotes/origin/side2
)
'
cat >test/expect <<\EOF
some-tag
EOF
test_expect_success 'add with reachable tags (default)' '
(
cd one &&
>foobar &&
git add foobar &&
git commit -m "Foobar" &&
git tag -a -m "Foobar tag" foobar-tag &&
git reset --hard HEAD~1 &&
git tag -a -m "Some tag" some-tag
) &&
mkdir add-tags &&
(
cd add-tags &&
git init &&
git remote add -f origin ../one &&
git tag -l some-tag >../test/output &&
git tag -l foobar-tag >>../test/output &&
test_must_fail git config remote.origin.tagopt
) &&
test_cmp test/expect test/output
'
cat >test/expect <<\EOF
some-tag
foobar-tag
--tags
EOF
test_expect_success 'add --tags' '
rm -rf add-tags &&
(
mkdir add-tags &&
cd add-tags &&
git init &&
git remote add -f --tags origin ../one &&
git tag -l some-tag >../test/output &&
git tag -l foobar-tag >>../test/output &&
git config remote.origin.tagopt >>../test/output
) &&
test_cmp test/expect test/output
'
cat >test/expect <<\EOF
--no-tags
EOF
test_expect_success 'add --no-tags' '
rm -rf add-tags &&
(
mkdir add-no-tags &&
cd add-no-tags &&
git init &&
git remote add -f --no-tags origin ../one &&
grep tagOpt .git/config &&
git tag -l some-tag >../test/output &&
git tag -l foobar-tag >../test/output &&
git config remote.origin.tagopt >>../test/output
) &&
(
cd one &&
git tag -d some-tag foobar-tag
) &&
test_cmp test/expect test/output
'
test_expect_success 'reject --no-no-tags' '
(
cd add-no-tags &&
test_must_fail git remote add -f --no-no-tags neworigin ../one
)
'
cat >one/expect <<\EOF
apis/main
apis/side
drosophila/another
drosophila/main
drosophila/side
EOF
test_expect_success 'update' '
(
cd one &&
git remote add drosophila ../two &&
git remote add apis ../mirror &&
git remote update &&
git branch -r >output &&
test_cmp expect output
)
'
cat >one/expect <<\EOF
drosophila/another
drosophila/main
drosophila/side
manduca/main
manduca/side
megaloprepus/main
megaloprepus/side
EOF
test_expect_success 'update with arguments' '
(
cd one &&
for b in $(git branch -r)
do
git branch -r -d $b || exit 1
done &&
git remote add manduca ../mirror &&
git remote add megaloprepus ../mirror &&
git config remotes.phobaeticus "drosophila megaloprepus" &&
git config remotes.titanus manduca &&
git remote update phobaeticus titanus &&
git branch -r >output &&
test_cmp expect output
)
'
test_expect_success 'update --prune' '
(
cd one &&
git branch -m side2 side3
) &&
(
cd test &&
git remote update --prune &&
(
cd ../one &&
git branch -m side3 side2
) &&
git rev-parse refs/remotes/origin/side3 &&
test_must_fail git rev-parse refs/remotes/origin/side2
)
'
cat >one/expect <<-\EOF
apis/main
apis/side
manduca/main
manduca/side
megaloprepus/main
megaloprepus/side
EOF
test_expect_success 'update default' '
(
cd one &&
for b in $(git branch -r)
do
git branch -r -d $b || exit 1
done &&
git config remote.drosophila.skipDefaultUpdate true &&
git remote update default &&
git branch -r >output &&
test_cmp expect output
)
'
cat >one/expect <<\EOF
drosophila/another
drosophila/main
drosophila/side
EOF
test_expect_success 'update default (overridden, with funny whitespace)' '
(
cd one &&
for b in $(git branch -r)
do
git branch -r -d $b || exit 1
done &&
git config remotes.default "$(printf "\t drosophila \n")" &&
git remote update default &&
git branch -r >output &&
test_cmp expect output
)
'
test_expect_success 'update (with remotes.default defined)' '
(
cd one &&
for b in $(git branch -r)
do
git branch -r -d $b || exit 1
done &&
git config remotes.default "drosophila" &&
git remote update &&
git branch -r >output &&
test_cmp expect output
)
'
test_expect_success '"remote show" does not show symbolic refs' '
git clone one three &&
(
cd three &&
git remote show origin >output &&
! grep "^ *HEAD$" < output &&
! grep -i stale < output
)
'
test_expect_success 'reject adding remote with an invalid name' '
test_must_fail git remote add some:url desired-name
'
# The first three test if the tracking branches are properly renamed,
# the last two ones check if the config is updated.
test_expect_success 'rename a remote' '
test_config_global remote.pushDefault origin &&
git clone one four &&
(
cd four &&
git config branch.main.pushRemote origin &&
builtin/remote.c: show progress when renaming remote references When renaming a remote, Git needs to rename all remote tracking references to the remote's new name (e.g., renaming "refs/remotes/old/foo" to "refs/remotes/new/foo" when renaming a remote from "old" to "new"). This can be somewhat slow when there are many references to rename, since each rename is done in a separate call to rename_ref() as opposed to grouping all renames together into the same transaction. It would be nice to execute all renames as a single transaction, but there is a snag: the reference transaction backend doesn't support renames during a transaction (only individually, via rename_ref()). The reasons there are described in more detail in [1], but the main problem is that in order to preserve the existing reflog, it must be moved while holding both locks (i.e., on "oldname" and "newname"), and the ref transaction code doesn't support inserting arbitrary actions into the middle of a transaction like that. As an aside, adding support for this to the ref transaction code is less straightforward than inserting both a ref_update() and ref_delete() call into the same transaction. rename_ref()'s special handling to detect D/F conflicts would need to be rewritten for the transaction code if we wanted to proactively catch D/F conflicts when renaming a reference during a transaction. The reftable backend could support this much more readily because of its lack of D/F conflicts. Instead of a more complex modification to the ref transaction code, display a progress meter when running verbosely in order to convince the user that Git is doing work while renaming a remote. This is mostly done as-expected, with the minor caveat that we intentionally count symrefs renames twice, since renaming a symref takes place over two separate calls (one to delete the old one, and another to create the new one). [1]: https://lore.kernel.org/git/572367B4.4050207@alum.mit.edu/ Suggested-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03 22:25:18 +00:00
GIT_TRACE2_EVENT=$(pwd)/trace \
git remote rename --progress origin upstream &&
test_region progress "Renaming remote references" trace &&
grep "pushRemote" .git/config &&
test -z "$(git for-each-ref refs/remotes/origin)" &&
test "$(git symbolic-ref refs/remotes/upstream/HEAD)" = "refs/remotes/upstream/main" &&
test "$(git rev-parse upstream/main)" = "$(git rev-parse main)" &&
test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/remotes/upstream/*" &&
test "$(git config branch.main.remote)" = "upstream" &&
test "$(git config branch.main.pushRemote)" = "upstream" &&
test "$(git config --global remote.pushDefault)" = "origin"
)
'
test_expect_success 'rename a remote renames repo remote.pushDefault' '
git clone one four.1 &&
(
cd four.1 &&
git config remote.pushDefault origin &&
git remote rename origin upstream &&
grep pushDefault .git/config &&
test "$(git config --local remote.pushDefault)" = "upstream"
)
'
test_expect_success 'rename a remote renames repo remote.pushDefault but ignores global' '
test_config_global remote.pushDefault other &&
git clone one four.2 &&
(
cd four.2 &&
git config remote.pushDefault origin &&
git remote rename origin upstream &&
test "$(git config --global remote.pushDefault)" = "other" &&
test "$(git config --local remote.pushDefault)" = "upstream"
)
'
test_expect_success 'rename a remote renames repo remote.pushDefault but keeps global' '
test_config_global remote.pushDefault origin &&
git clone one four.3 &&
(
cd four.3 &&
git config remote.pushDefault origin &&
git remote rename origin upstream &&
test "$(git config --global remote.pushDefault)" = "origin" &&
test "$(git config --local remote.pushDefault)" = "upstream"
)
'
test_expect_success 'rename handles remote without fetch refspec' '
git clone --bare one no-refspec.git &&
# confirm assumption that bare clone does not create refspec
test_expect_code 5 \
git -C no-refspec.git config --unset-all remote.origin.fetch &&
git -C no-refspec.git config remote.origin.url >expect &&
git -C no-refspec.git remote rename origin foo &&
git -C no-refspec.git config remote.foo.url >actual &&
test_cmp expect actual
'
test_expect_success 'rename does not update a non-default fetch refspec' '
git clone one four.one &&
(
cd four.one &&
git config remote.origin.fetch +refs/heads/*:refs/heads/origin/* &&
git remote rename origin upstream &&
test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/heads/origin/*" &&
git rev-parse -q origin/main
)
'
test_expect_success 'rename a remote with name part of fetch spec' '
git clone one four.two &&
(
cd four.two &&
git remote rename origin remote &&
git remote rename remote upstream &&
test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/remotes/upstream/*"
)
'
test_expect_success 'rename a remote with name prefix of other remote' '
git clone one four.three &&
(
cd four.three &&
git remote add o git://example.com/repo.git &&
git remote rename o upstream &&
test "$(git rev-parse origin/main)" = "$(git rev-parse main)"
)
'
remote rename: more carefully determine whether a remote is configured One of the really nice features of the ~/.gitconfig file is that users can override defaults by their own preferred settings for all of their repositories. One such default that some users like to override is whether the "origin" remote gets auto-pruned or not. The user would simply call git config --global remote.origin.prune true and from now on all "origin" remotes would be pruned automatically when fetching into the local repository. There is just one catch: now Git thinks that the "origin" remote is configured, even if the repository config has no [remote "origin"] section at all, as it does not realize that the "prune" setting was configured globally and that there really is no "origin" remote configured in this repository. That is a problem e.g. when renaming a remote to a new name, when Git may be fooled into thinking that there is already a remote of that new name. Let's fix this by paying more attention to *where* the remote settings came from: if they are configured in the local repository config, we must not overwrite them. If they were configured elsewhere, we cannot overwrite them to begin with, as we only write the repository config. There is only one caller of remote_is_configured() (in `git fetch`) that may want to take remotes into account even if they were configured outside the repository config; all other callers essentially try to prevent the Git command from overwriting settings in the repository config. To accommodate that fact, the remote_is_configured() function now requires a parameter that states whether the caller is interested in all remotes, or only in those that were configured in the repository config. Many thanks to Jeff King whose tireless review helped with settling for nothing less than the current strategy. This fixes https://github.com/git-for-windows/git/issues/888 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19 21:20:02 +00:00
test_expect_success 'rename succeeds with existing remote.<target>.prune' '
git clone one four.four &&
test_when_finished git config --global --unset remote.upstream.prune &&
git config --global remote.upstream.prune true &&
git -C four.four remote rename origin upstream
'
test_expect_success 'remove a remote' '
test_config_global remote.pushDefault origin &&
git clone one four.five &&
(
cd four.five &&
git config branch.main.pushRemote origin &&
git remote remove origin &&
test -z "$(git for-each-ref refs/remotes/origin)" &&
test_must_fail git config branch.main.remote &&
test_must_fail git config branch.main.pushRemote &&
test "$(git config --global remote.pushDefault)" = "origin"
)
'
test_expect_success 'remove a remote removes repo remote.pushDefault' '
git clone one four.five.1 &&
(
cd four.five.1 &&
git config remote.pushDefault origin &&
git remote remove origin &&
test_must_fail git config --local remote.pushDefault
)
'
test_expect_success 'remove a remote removes repo remote.pushDefault but ignores global' '
test_config_global remote.pushDefault other &&
git clone one four.five.2 &&
(
cd four.five.2 &&
git config remote.pushDefault origin &&
git remote remove origin &&
test "$(git config --global remote.pushDefault)" = "other" &&
test_must_fail git config --local remote.pushDefault
)
'
test_expect_success 'remove a remote removes repo remote.pushDefault but keeps global' '
test_config_global remote.pushDefault origin &&
git clone one four.five.3 &&
(
cd four.five.3 &&
git config remote.pushDefault origin &&
git remote remove origin &&
test "$(git config --global remote.pushDefault)" = "origin" &&
test_must_fail git config --local remote.pushDefault
)
'
cat >remotes_origin <<EOF
URL: $(pwd)/one
Push: refs/heads/main:refs/heads/upstream
Push: refs/heads/next:refs/heads/upstream2
Pull: refs/heads/main:refs/heads/origin
Pull: refs/heads/next:refs/heads/origin2
EOF
test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
git clone one five &&
origin_url=$(pwd)/one &&
(
cd five &&
git remote remove origin &&
mkdir -p .git/remotes &&
cat ../remotes_origin >.git/remotes/origin &&
git remote rename origin origin &&
test_path_is_missing .git/remotes/origin &&
test "$(git config remote.origin.url)" = "$origin_url" &&
cat >push_expected <<-\EOF &&
refs/heads/main:refs/heads/upstream
refs/heads/next:refs/heads/upstream2
EOF
cat >fetch_expected <<-\EOF &&
refs/heads/main:refs/heads/origin
refs/heads/next:refs/heads/origin2
EOF
git config --get-all remote.origin.push >push_actual &&
git config --get-all remote.origin.fetch >fetch_actual &&
test_cmp push_expected push_actual &&
test_cmp fetch_expected fetch_actual
)
'
test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' '
tests: don't depend on template-created .git/branches As noted in c8a58ac5a52 (Revert "Don't create the $GIT_DIR/branches directory on init", 2009-10-31) there was an attempt long ago in 0cc5691a8b0 (Don't create the $GIT_DIR/branches directory on init, 2009-10-30) to get rid of the legacy "branches" directory. We should probably get rid of its creation by removing the "templates/branches--" file. But whatever our default behavior, our tests should be tightened up to explicitly create the .git/branches directory if they rely on our default templates, to make the dependency on those templates clear. So let's amend the two tests that would fail if .git/branches wasn't created. To do this introduce a new "TEST_CREATE_REPO_NO_TEMPLATE" variable, which we'll set before sourcing test-lib.sh, and change the "git clone" and "git init" commands in the tests themselves to explicitly pass "--template=". This way they won't get a .git/branches in either their top-level .git, or in the ones they create. We can then amend the tests that rely on the ".git/branches" directory existing to create it explicitly, and to remove it after its creation. This new "TEST_CREATE_REPO_NO_TEMPLATE" variable is a less heavy-handed version of the "NO_SET_GIT_TEMPLATE_DIR" variable. See a94d305bf80 (t/t0001-init.sh: add test for 'init with init.templatedir set', 2010-02-26) for its implementation. Unlike "TEST_CREATE_REPO_NO_TEMPLATE", this new "TEST_CREATE_REPO_NO_TEMPLATE" variable is narrowly scoped to what the "git init" in test-lib.sh does, as opposed to the global effect of "NO_SET_GIT_TEMPLATE_DIR" and the setting of "GIT_TEMPLATE_DIR" in wrap-for-bin.sh. I experimented with adding a new "GIT_WRAP_FOR_BIN_VIA_TEST_LIB" variable set in test-lib.sh, which would cause wrap-for-bin.sh to not set GIT_TEMPLATE_DIR, GITPERLLIB etc, as we set those in test-lib.sh. I think that's a viable approach, but it would interact e.g. with the appending feature of GITPERLLIB added in 8bade1e12e2 (wrap-for-bin: make bin-wrappers chainable, 2013-07-04). Doing so would allow us to convert the tests in t0001-init.sh that now use "NO_SET_GIT_TEMPLATE_DIR" to simply unset "GIT_TEMPLATE_DIR" in a sub-shell before invoking "git init" or "git clone". I think that approach is worth pursuing, but let's table it for now. Some future wrap-for-bin.sh refactoring can try to address it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-03 11:15:04 +00:00
git clone --template= one six &&
origin_url=$(pwd)/one &&
(
cd six &&
git remote rm origin &&
tests: don't depend on template-created .git/branches As noted in c8a58ac5a52 (Revert "Don't create the $GIT_DIR/branches directory on init", 2009-10-31) there was an attempt long ago in 0cc5691a8b0 (Don't create the $GIT_DIR/branches directory on init, 2009-10-30) to get rid of the legacy "branches" directory. We should probably get rid of its creation by removing the "templates/branches--" file. But whatever our default behavior, our tests should be tightened up to explicitly create the .git/branches directory if they rely on our default templates, to make the dependency on those templates clear. So let's amend the two tests that would fail if .git/branches wasn't created. To do this introduce a new "TEST_CREATE_REPO_NO_TEMPLATE" variable, which we'll set before sourcing test-lib.sh, and change the "git clone" and "git init" commands in the tests themselves to explicitly pass "--template=". This way they won't get a .git/branches in either their top-level .git, or in the ones they create. We can then amend the tests that rely on the ".git/branches" directory existing to create it explicitly, and to remove it after its creation. This new "TEST_CREATE_REPO_NO_TEMPLATE" variable is a less heavy-handed version of the "NO_SET_GIT_TEMPLATE_DIR" variable. See a94d305bf80 (t/t0001-init.sh: add test for 'init with init.templatedir set', 2010-02-26) for its implementation. Unlike "TEST_CREATE_REPO_NO_TEMPLATE", this new "TEST_CREATE_REPO_NO_TEMPLATE" variable is narrowly scoped to what the "git init" in test-lib.sh does, as opposed to the global effect of "NO_SET_GIT_TEMPLATE_DIR" and the setting of "GIT_TEMPLATE_DIR" in wrap-for-bin.sh. I experimented with adding a new "GIT_WRAP_FOR_BIN_VIA_TEST_LIB" variable set in test-lib.sh, which would cause wrap-for-bin.sh to not set GIT_TEMPLATE_DIR, GITPERLLIB etc, as we set those in test-lib.sh. I think that's a viable approach, but it would interact e.g. with the appending feature of GITPERLLIB added in 8bade1e12e2 (wrap-for-bin: make bin-wrappers chainable, 2013-07-04). Doing so would allow us to convert the tests in t0001-init.sh that now use "NO_SET_GIT_TEMPLATE_DIR" to simply unset "GIT_TEMPLATE_DIR" in a sub-shell before invoking "git init" or "git clone". I think that approach is worth pursuing, but let's table it for now. Some future wrap-for-bin.sh refactoring can try to address it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-03 11:15:04 +00:00
mkdir .git/branches &&
echo "$origin_url#main" >.git/branches/origin &&
git remote rename origin origin &&
test_path_is_missing .git/branches/origin &&
test "$(git config remote.origin.url)" = "$origin_url" &&
test "$(git config remote.origin.fetch)" = "refs/heads/main:refs/heads/origin" &&
test "$(git config remote.origin.push)" = "HEAD:refs/heads/main"
)
'
test_expect_success 'migrate a remote from named file in $GIT_DIR/branches (2)' '
tests: don't depend on template-created .git/branches As noted in c8a58ac5a52 (Revert "Don't create the $GIT_DIR/branches directory on init", 2009-10-31) there was an attempt long ago in 0cc5691a8b0 (Don't create the $GIT_DIR/branches directory on init, 2009-10-30) to get rid of the legacy "branches" directory. We should probably get rid of its creation by removing the "templates/branches--" file. But whatever our default behavior, our tests should be tightened up to explicitly create the .git/branches directory if they rely on our default templates, to make the dependency on those templates clear. So let's amend the two tests that would fail if .git/branches wasn't created. To do this introduce a new "TEST_CREATE_REPO_NO_TEMPLATE" variable, which we'll set before sourcing test-lib.sh, and change the "git clone" and "git init" commands in the tests themselves to explicitly pass "--template=". This way they won't get a .git/branches in either their top-level .git, or in the ones they create. We can then amend the tests that rely on the ".git/branches" directory existing to create it explicitly, and to remove it after its creation. This new "TEST_CREATE_REPO_NO_TEMPLATE" variable is a less heavy-handed version of the "NO_SET_GIT_TEMPLATE_DIR" variable. See a94d305bf80 (t/t0001-init.sh: add test for 'init with init.templatedir set', 2010-02-26) for its implementation. Unlike "TEST_CREATE_REPO_NO_TEMPLATE", this new "TEST_CREATE_REPO_NO_TEMPLATE" variable is narrowly scoped to what the "git init" in test-lib.sh does, as opposed to the global effect of "NO_SET_GIT_TEMPLATE_DIR" and the setting of "GIT_TEMPLATE_DIR" in wrap-for-bin.sh. I experimented with adding a new "GIT_WRAP_FOR_BIN_VIA_TEST_LIB" variable set in test-lib.sh, which would cause wrap-for-bin.sh to not set GIT_TEMPLATE_DIR, GITPERLLIB etc, as we set those in test-lib.sh. I think that's a viable approach, but it would interact e.g. with the appending feature of GITPERLLIB added in 8bade1e12e2 (wrap-for-bin: make bin-wrappers chainable, 2013-07-04). Doing so would allow us to convert the tests in t0001-init.sh that now use "NO_SET_GIT_TEMPLATE_DIR" to simply unset "GIT_TEMPLATE_DIR" in a sub-shell before invoking "git init" or "git clone". I think that approach is worth pursuing, but let's table it for now. Some future wrap-for-bin.sh refactoring can try to address it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-03 11:15:04 +00:00
git clone --template= one seven &&
(
cd seven &&
git remote rm origin &&
tests: don't depend on template-created .git/branches As noted in c8a58ac5a52 (Revert "Don't create the $GIT_DIR/branches directory on init", 2009-10-31) there was an attempt long ago in 0cc5691a8b0 (Don't create the $GIT_DIR/branches directory on init, 2009-10-30) to get rid of the legacy "branches" directory. We should probably get rid of its creation by removing the "templates/branches--" file. But whatever our default behavior, our tests should be tightened up to explicitly create the .git/branches directory if they rely on our default templates, to make the dependency on those templates clear. So let's amend the two tests that would fail if .git/branches wasn't created. To do this introduce a new "TEST_CREATE_REPO_NO_TEMPLATE" variable, which we'll set before sourcing test-lib.sh, and change the "git clone" and "git init" commands in the tests themselves to explicitly pass "--template=". This way they won't get a .git/branches in either their top-level .git, or in the ones they create. We can then amend the tests that rely on the ".git/branches" directory existing to create it explicitly, and to remove it after its creation. This new "TEST_CREATE_REPO_NO_TEMPLATE" variable is a less heavy-handed version of the "NO_SET_GIT_TEMPLATE_DIR" variable. See a94d305bf80 (t/t0001-init.sh: add test for 'init with init.templatedir set', 2010-02-26) for its implementation. Unlike "TEST_CREATE_REPO_NO_TEMPLATE", this new "TEST_CREATE_REPO_NO_TEMPLATE" variable is narrowly scoped to what the "git init" in test-lib.sh does, as opposed to the global effect of "NO_SET_GIT_TEMPLATE_DIR" and the setting of "GIT_TEMPLATE_DIR" in wrap-for-bin.sh. I experimented with adding a new "GIT_WRAP_FOR_BIN_VIA_TEST_LIB" variable set in test-lib.sh, which would cause wrap-for-bin.sh to not set GIT_TEMPLATE_DIR, GITPERLLIB etc, as we set those in test-lib.sh. I think that's a viable approach, but it would interact e.g. with the appending feature of GITPERLLIB added in 8bade1e12e2 (wrap-for-bin: make bin-wrappers chainable, 2013-07-04). Doing so would allow us to convert the tests in t0001-init.sh that now use "NO_SET_GIT_TEMPLATE_DIR" to simply unset "GIT_TEMPLATE_DIR" in a sub-shell before invoking "git init" or "git clone". I think that approach is worth pursuing, but let's table it for now. Some future wrap-for-bin.sh refactoring can try to address it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-03 11:15:04 +00:00
mkdir .git/branches &&
echo "quux#foom" > .git/branches/origin &&
git remote rename origin origin &&
test_path_is_missing .git/branches/origin &&
test "$(git config remote.origin.url)" = "quux" &&
test "$(git config remote.origin.fetch)" = "refs/heads/foom:refs/heads/origin" &&
test "$(git config remote.origin.push)" = "HEAD:refs/heads/foom"
)
'
test_expect_success 'remote prune to cause a dangling symref' '
git clone one eight &&
(
cd one &&
git checkout side2 &&
git branch -D main
) &&
(
cd eight &&
git remote prune origin
) >err 2>&1 &&
test_i18ngrep "has become dangling" err &&
: And the dangling symref will not cause other annoying errors &&
(
cd eight &&
git branch -a
) 2>err &&
! grep "points nowhere" err &&
(
cd eight &&
test_must_fail git branch nomore origin
) 2>err &&
test_i18ngrep "dangling symref" err
'
test_expect_success 'show empty remote' '
test_create_repo empty &&
git clone empty empty-clone &&
(
cd empty-clone &&
git remote show origin
)
'
test_expect_success 'remote set-branches requires a remote' '
test_must_fail git remote set-branches &&
test_must_fail git remote set-branches --add
'
test_expect_success 'remote set-branches' '
echo "+refs/heads/*:refs/remotes/scratch/*" >expect.initial &&
sort <<-\EOF >expect.add &&
+refs/heads/*:refs/remotes/scratch/*
+refs/heads/other:refs/remotes/scratch/other
EOF
sort <<-\EOF >expect.replace &&
+refs/heads/maint:refs/remotes/scratch/maint
+refs/heads/main:refs/remotes/scratch/main
+refs/heads/next:refs/remotes/scratch/next
EOF
sort <<-\EOF >expect.add-two &&
+refs/heads/maint:refs/remotes/scratch/maint
+refs/heads/main:refs/remotes/scratch/main
+refs/heads/next:refs/remotes/scratch/next
+refs/heads/seen:refs/remotes/scratch/seen
+refs/heads/t/topic:refs/remotes/scratch/t/topic
EOF
sort <<-\EOF >expect.setup-ffonly &&
refs/heads/main:refs/remotes/scratch/main
+refs/heads/next:refs/remotes/scratch/next
EOF
sort <<-\EOF >expect.respect-ffonly &&
refs/heads/main:refs/remotes/scratch/main
+refs/heads/next:refs/remotes/scratch/next
+refs/heads/seen:refs/remotes/scratch/seen
EOF
git clone .git/ setbranches &&
(
cd setbranches &&
git remote rename origin scratch &&
git config --get-all remote.scratch.fetch >config-result &&
sort <config-result >../actual.initial &&
git remote set-branches scratch --add other &&
git config --get-all remote.scratch.fetch >config-result &&
sort <config-result >../actual.add &&
git remote set-branches scratch maint main next &&
git config --get-all remote.scratch.fetch >config-result &&
sort <config-result >../actual.replace &&
git remote set-branches --add scratch seen t/topic &&
git config --get-all remote.scratch.fetch >config-result &&
sort <config-result >../actual.add-two &&
git config --unset-all remote.scratch.fetch &&
git config remote.scratch.fetch \
refs/heads/main:refs/remotes/scratch/main &&
git config --add remote.scratch.fetch \
+refs/heads/next:refs/remotes/scratch/next &&
git config --get-all remote.scratch.fetch >config-result &&
sort <config-result >../actual.setup-ffonly &&
git remote set-branches --add scratch seen &&
git config --get-all remote.scratch.fetch >config-result &&
sort <config-result >../actual.respect-ffonly
) &&
test_cmp expect.initial actual.initial &&
test_cmp expect.add actual.add &&
test_cmp expect.replace actual.replace &&
test_cmp expect.add-two actual.add-two &&
test_cmp expect.setup-ffonly actual.setup-ffonly &&
test_cmp expect.respect-ffonly actual.respect-ffonly
'
test_expect_success 'remote set-branches with --mirror' '
echo "+refs/*:refs/*" >expect.initial &&
echo "+refs/heads/main:refs/heads/main" >expect.replace &&
git clone --mirror .git/ setbranches-mirror &&
(
cd setbranches-mirror &&
git remote rename origin scratch &&
git config --get-all remote.scratch.fetch >../actual.initial &&
git remote set-branches scratch heads/main &&
git config --get-all remote.scratch.fetch >../actual.replace
) &&
test_cmp expect.initial actual.initial &&
test_cmp expect.replace actual.replace
'
test_expect_success 'new remote' '
git remote add someremote foo &&
echo foo >expect &&
git config --get-all remote.someremote.url >actual &&
cmp expect actual
'
get_url_test () {
cat >expect &&
git remote get-url "$@" >actual &&
test_cmp expect actual
}
test_expect_success 'get-url on new remote' '
echo foo | get_url_test someremote &&
echo foo | get_url_test --all someremote &&
echo foo | get_url_test --push someremote &&
echo foo | get_url_test --push --all someremote
'
test_expect_success 'remote set-url with locked config' '
test_when_finished "rm -f .git/config.lock" &&
git config --get-all remote.someremote.url >expect &&
>.git/config.lock &&
test_must_fail git remote set-url someremote baz &&
git config --get-all remote.someremote.url >actual &&
cmp expect actual
'
test_expect_success 'remote set-url bar' '
git remote set-url someremote bar &&
echo bar >expect &&
git config --get-all remote.someremote.url >actual &&
cmp expect actual
'
test_expect_success 'remote set-url baz bar' '
git remote set-url someremote baz bar &&
echo baz >expect &&
git config --get-all remote.someremote.url >actual &&
cmp expect actual
'
test_expect_success 'remote set-url zot bar' '
test_must_fail git remote set-url someremote zot bar &&
echo baz >expect &&
git config --get-all remote.someremote.url >actual &&
cmp expect actual
'
test_expect_success 'remote set-url --push zot baz' '
test_must_fail git remote set-url --push someremote zot baz &&
echo "YYY" >expect &&
echo baz >>expect &&
test_must_fail git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --push zot' '
git remote set-url --push someremote zot &&
echo zot >expect &&
echo "YYY" >>expect &&
echo baz >>expect &&
git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'get-url with different urls' '
echo baz | get_url_test someremote &&
echo baz | get_url_test --all someremote &&
echo zot | get_url_test --push someremote &&
echo zot | get_url_test --push --all someremote
'
test_expect_success 'remote set-url --push qux zot' '
git remote set-url --push someremote qux zot &&
echo qux >expect &&
echo "YYY" >>expect &&
echo baz >>expect &&
git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --push foo qu+x' '
git remote set-url --push someremote foo qu+x &&
echo foo >expect &&
echo "YYY" >>expect &&
echo baz >>expect &&
git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --push --add aaa' '
git remote set-url --push --add someremote aaa &&
echo foo >expect &&
echo aaa >>expect &&
echo "YYY" >>expect &&
echo baz >>expect &&
git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'get-url on multi push remote' '
echo foo | get_url_test --push someremote &&
get_url_test --push --all someremote <<-\EOF
foo
aaa
EOF
'
test_expect_success 'remote set-url --push bar aaa' '
git remote set-url --push someremote bar aaa &&
echo foo >expect &&
echo bar >>expect &&
echo "YYY" >>expect &&
echo baz >>expect &&
git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --push --delete bar' '
git remote set-url --push --delete someremote bar &&
echo foo >expect &&
echo "YYY" >>expect &&
echo baz >>expect &&
git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --push --delete foo' '
git remote set-url --push --delete someremote foo &&
echo "YYY" >expect &&
echo baz >>expect &&
test_must_fail git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --add bbb' '
git remote set-url --add someremote bbb &&
echo "YYY" >expect &&
echo baz >>expect &&
echo bbb >>expect &&
test_must_fail git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'get-url on multi fetch remote' '
echo baz | get_url_test someremote &&
get_url_test --all someremote <<-\EOF
baz
bbb
EOF
'
test_expect_success 'remote set-url --delete .*' '
test_must_fail git remote set-url --delete someremote .\* &&
echo "YYY" >expect &&
echo baz >>expect &&
echo bbb >>expect &&
test_must_fail git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --delete bbb' '
git remote set-url --delete someremote bbb &&
echo "YYY" >expect &&
echo baz >>expect &&
test_must_fail git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --delete baz' '
test_must_fail git remote set-url --delete someremote baz &&
echo "YYY" >expect &&
echo baz >>expect &&
test_must_fail git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --add ccc' '
git remote set-url --add someremote ccc &&
echo "YYY" >expect &&
echo baz >>expect &&
echo ccc >>expect &&
test_must_fail git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'remote set-url --delete baz' '
git remote set-url --delete someremote baz &&
echo "YYY" >expect &&
echo ccc >>expect &&
test_must_fail git config --get-all remote.someremote.pushurl >actual &&
echo "YYY" >>actual &&
git config --get-all remote.someremote.url >>actual &&
cmp expect actual
'
test_expect_success 'extra args: setup' '
# add a dummy origin so that this does not trigger failure
git remote add origin .
'
test_extra_arg () {
test_expect_success "extra args: $*" "
test_must_fail git remote $* bogus_extra_arg 2>actual &&
test_i18ngrep '^usage:' actual
"
}
test_extra_arg add nick url
test_extra_arg rename origin newname
test_extra_arg remove origin
test_extra_arg set-head origin main
# set-branches takes any number of args
test_extra_arg get-url origin newurl
test_extra_arg set-url origin newurl oldurl
# show takes any number of args
# prune takes any number of args
# update takes any number of args
test_expect_success 'add remote matching the "insteadOf" URL' '
git config url.xyz@example.com.insteadOf backup &&
git remote add backup xyz@example.com
'
test_expect_success 'unqualified <dst> refspec DWIM and advice' '
test_when_finished "(cd test && git tag -d some-tag)" &&
(
cd test &&
git tag -a -m "Some tag" some-tag main &&
for type in commit tag tree blob
do
if test "$type" = "blob"
then
oid=$(git rev-parse some-tag:file)
else
oid=$(git rev-parse some-tag^{$type})
fi &&
test_must_fail git push origin $oid:dst 2>err &&
test_i18ngrep "error: The destination you" err &&
test_i18ngrep "hint: Did you mean" err &&
test_must_fail git -c advice.pushUnqualifiedRefName=false \
push origin $oid:dst 2>err &&
test_i18ngrep "error: The destination you" err &&
test_i18ngrep ! "hint: Did you mean" err ||
exit 1
done
)
'
test_expect_success 'refs/remotes/* <src> refspec and unqualified <dst> DWIM and advice' '
(
cd two &&
git tag -a -m "Some tag" my-tag main &&
git update-ref refs/trees/my-head-tree HEAD^{tree} &&
git update-ref refs/blobs/my-file-blob HEAD:file
) &&
(
cd test &&
git config --add remote.two.fetch "+refs/tags/*:refs/remotes/tags-from-two/*" &&
git config --add remote.two.fetch "+refs/trees/*:refs/remotes/trees-from-two/*" &&
git config --add remote.two.fetch "+refs/blobs/*:refs/remotes/blobs-from-two/*" &&
git fetch --no-tags two &&
test_must_fail git push origin refs/remotes/two/another:dst 2>err &&
test_i18ngrep "error: The destination you" err &&
test_must_fail git push origin refs/remotes/tags-from-two/my-tag:dst-tag 2>err &&
test_i18ngrep "error: The destination you" err &&
test_must_fail git push origin refs/remotes/trees-from-two/my-head-tree:dst-tree 2>err &&
test_i18ngrep "error: The destination you" err &&
test_must_fail git push origin refs/remotes/blobs-from-two/my-file-blob:dst-blob 2>err &&
test_i18ngrep "error: The destination you" err
)
'
test_done