git bash 使用 Visual Studio Team Services (VSTS) 克隆不正确的 url

Question

我和办公室的一个人有一个非常奇怪的问题，我们将存储库从 TFS 中的一个项目转移到另一个项目（我将在这里使用 TFS，但我的意思是 Visual Studio Team Services，它基本上是 TFS在云端）。

所以我们的 repo 曾经住在这样的地方：

https://somewhere.visualstudio.com/projects/_git/something

然后它被复制到另一个项目并删除了旧的，所以它现在位于：

https://somewhere.visualstudio.com/project_two/_git/something

当这里的一个人尝试从新的 repo url 克隆时：

git clone https://somewhere.visualstudio.com/project_two/_git/something

他得到了错误：

远程：TF401019：具有名称或标识符的 Git 存储库 不存在或您无权执行您的操作 正在尝试。致命的：存储库 'https://somewhere.visualstudio.com/projects/_git/something' 未找到

好像某处有一些缓存似乎将新的 repo url 重定向到不再存在的旧的 repo url。我的电脑上不会发生这种情况。

那么在 GIT 的幕后有什么东西会导致这个 repo url 被缓存在某个地方，或者 TFS 中有什么东西会导致这种行为吗？

== 详细输出 ==

somename@cf-l-003242 MINGW64 /d/Repos
$ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone https://somewhere.visualstudio.com/project_two/_git/something
10:50:02.761600 git.c:349               trace: built-in: git 'clone' 'https://somewhere.visualstudio.com/project_two/_git/something'
Cloning into 'something'...
10:50:02.801600 run-command.c:336       trace: run_command: 'git-remote-https' 'origin' 'https://somewhere.visualstudio.com/projects/_git/something'

所以看起来源头搞砸了，但是他已经卸载并重新安装了 git，并且正在将一个 repo 克隆到一个新文件夹，所以我不知道为什么它会搞砸源头。

Answer 1

解决方案

问题是全局 Git 配置文件（~/.gitconfig）有一个origin的配置：

[remote "origin"]
    url = https://somewhere.visualstudio.com/projects/_git/something

删除此部分已修复问题。

说明

Git 使用配置文件来存储用户偏好和存储库信息。每个仓库都有自己的配置文件（仓库目录下的.git/config），还有一个全局配置文件~/.gitconfig。

git config 命令可以修改这些文件。它默认修改存储库配置文件，并有一个标志--global 来修改全局配置文件。这些文件也可以使用文本编辑器进行编辑。

通常，用户首选项存储在全局配置文件中，存储库信息存储在每个存储库文件中。但不一定是这样。

例如，我的全名和电子邮件地址存储在我的全局配置文件中。如果我想在特定存储库中工作时使用不同的电子邮件地址，我可以在该存储库的配置文件中设置电子邮件地址。

相反，存储库信息可以存储在全局配置文件中，为所有存储库提供默认值。这可能会产生意想不到的后果。特别是，如果 origin 的 URL 是使用

全局设置的

git config --global remote.origin.url https://xyz  # WARNING: Causes weirdness

那么任何通过 HTTP(S) 或 SSH 克隆存储库的尝试都将导致获取https://xyz，无论命令行中指定的 URL 是什么（使用 Git 1.7.9.5 和 Git 2.10.2 测试）。

要解决这个问题，请使用文本编辑器打开 ~/.gitconfig 并删除不应该是全局的选项。首先进行备份，如果您不确定某个选项的作用，请参阅git help config。

调试说明

这是我用来发现问题原因的步骤。

输出

GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone ...

显示 git.c 的第 349 行中的 URL 是正确的，但 run-command.c 的第 336 行中的 URL 是错误的。我决定在调试器 (gdb) 中运行 Git，看看这两点之间发生了什么。

我从源代码编译了最新版本的 Git 以获取调试符号。问题中的行号和我下载的版本相匹配，很方便（获取相同版本的Git会更好）。

当我单步执行代码时，我注意到在 builtin/clone.c 的第 991 行中调用了 remote_get()。这个函数读取配置，这似乎是一个可以出现新 URL 的地方。我在全局设置了remote.origin.url，并成功复制了问题中的行为。

从源代码编译 Git 并在调试器中单步执行并不是普通用户应该做的事情。另一位有经验的 Git 用户可能会立即怀疑全局配置文件，因为它在重新安装后仍然存在。