Bug: the output of "git remote" can be confused by global config settings

Bug: the output of "git remote" can be confused by global config settings

[Daniel Martin]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

git config --global remote.origin.tagopt --notags
# much later
mkdir /tmp/test_dir && cd /tmp/test_dir
git init .
git remote
git remote remove origin
git remote -v

What did you expect to happen? (Expected behavior)
I expected "git remote" to report only on the remotes that existed in that newly created repository.

I expected "git remote remove origin" to succeed since "git remote" lied and told me that the newly
created repo had a remote inside it called "origin".

What happened instead? (Actual behavior)

The global remote.origin.tagopt config setting convinced "git remote" that there was always a
remote called "origin" present, even in a brand new repository.

"git remove" could tell that there was no remote called "origin":

test_dir$ git remote
origin
test_dir$ git remote remove origin
error: No such remote: 'origin'
test_dir$ git remote -v
origin	

What's different between what you expected and what actually happened?

The global config setting should not artificially create a remote from the point of
view of "git remote", which should look only at the current repo's configuration and not at
the global or system configuration.

Anything else you want to add:



[System Info]
git version:
git version 2.32.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 19.6.0 Darwin Kernel Version 19.6.0: Tue Jun 22 19:49:55 PDT 2021; root:xnu-6153.141.35~1/RELEASE_X86_64 x86_64
compiler info: clang: 12.0.0 (clang-1200.0.32.29)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]