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

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]