remote rename: demonstrate a bogus "remote exists" bug

Some users like to set `remote.origin.prune = true` in their ~/.gitconfig
so that all of their repositories use that default.

However, our code is ill-prepared for this, mistaking that single entry to
mean that there is already a remote of the name "origin", even if there is
not.

This patch adds a test case demonstrating this issue.

Reported by Andrew Arnott.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 8198d8eb05c5366c7d61a12351c333902a2265b6..2c03f44c85991ce57f59b671f5d3e3ce1025a1bf 100755 (executable)
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -764,6 +764,13 @@ test_expect_success 'rename a remote with name prefix of other remote' '
        )
 '
 
+test_expect_failure '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
+'
+
 cat >remotes_origin <<EOF
 URL: $(pwd)/one
 Push: refs/heads/master:refs/heads/upstream