git - 为什么 git submodule update 失败并显示 "fatal: remote error: upload-pack: not our ref"？

Question

我有一个带有多个子模块的 git repo。我已经尝试删除和添加有问题的子模块( scopatz's nanorc )，但是在删除和重新添加过程中错误仍然存​​在。当我将 repo 克隆到新位置时，我会使用 git submodule update --init --recursive 自动更新它，这是失败的时候，但仅限于这个子模块......
下面是命令的相关输出 GIT_TRACE=2 :

23:01:26.918691 run-command.c:1569      run_processes_parallel: preparing to run up to 1 tasks
23:01:26.933567 run-command.c:1601      run_processes_parallel: done
23:01:26.934373 run-command.c:646       trace: run_command: git gc --auto
23:01:26.966805 git.c:344               trace: built-in: git gc --auto
23:01:26.991059 git.c:344               trace: built-in: git rev-parse --local-env-vars
23:01:27.015684 git.c:344               trace: built-in: git rev-parse --local-env-vars
23:01:27.032282 git.c:344               trace: built-in: git symbolic-ref -q HEAD
23:01:27.053948 git.c:344               trace: built-in: git config --get branch.master.remote
23:01:27.073636 git.c:344               trace: built-in: git fetch origin 151d94a8754b0a612315fc191c5373cc0055c13d
23:01:27.079657 run-command.c:646       trace: run_command: git-remote-https origin https://github.com/scopatz/nanorc.git
23:01:28.441725 run-command.c:646       trace: run_command: git rev-list --objects --stdin --not --all --quiet
23:01:28.452267 run-command.c:646       trace: run_command: git fetch-pack --stateless-rpc --stdin --lock-pack --thin https://github.com/scopatz/nanorc.git/
23:01:28.467757 git.c:344               trace: built-in: git fetch-pack --stateless-rpc --stdin --lock-pack --thin https://github.com/scopatz/nanorc.git/
fatal: remote error: upload-pack: not our ref 151d94a8754b0a612315fc191c5373cc0055c13d
fatal: The remote end hung up unexpectedly
Fetched in submodule path 'submodules/nano', but it did not contain 151d94a8754b0a612315fc191c5373cc0055c13d. Direct fetching of that commit failed.

希望这里有人可以提供帮助，此时我大部分时间都迷路了。

=== 编辑:下面的解决方案步骤 ===

cd {submodule path}
git reset --hard origin/master
cd -
git clean -n
git add {submodule path}
git commit
git submodule update --init --recursive

没有错误，太棒了。

Answer 1

使用 Git 和子模块，您可以从至少两个 Git 存储库开始。一个是“你的”存储库——主要的，Git 将其称为 super 项目。第二个 Git 存储库是其他 Git 存储库:它并没有什么特别之处。只是您的 super 项目包含以下两个部分:

克隆子模块的说明。这让你的 Git 运行 git clone如果需要，在 git submodule update --init 期间例如。

应该在其他 Git 存储库中的某个提交的原始哈希 ID。在克隆或运行 git fetch 之后，您的主存储库将如果在您克隆另一个 Git 存储库中合适，请运行 git checkout hash使用这个原始哈希 ID。

您的 super 项目要求提供哈希 ID 151d94a8754b0a612315fc191c5373cc0055c13d在 Git 存储库中，您可以从 https://github.com/scopatz/nanorc.git 克隆.该提交根本不存在于该存储库中，因此它也不存在于您制作的任何克隆中。

你知道为什么你的 super 项目会列出这个提交哈希 ID，即使它不存在？ (我当然不知道。)你不能从他们的 Git 中得到它，因为他们没有。这就是所有这些错误消息告诉你的。

您可以尝试在其他存储库(或 Google)中搜索 151d94a8754b0a612315fc191c5373cc0055c13d (我刚用谷歌试过，他们找不到)。或者，如果你并不特别关心那个提交，试着告诉你自己的 Git——你的 super 项目——它应该得到一些其他的提交，一个确实存在，因此你可以得到。

你应该得到哪个提交？我不知道:这取决于你。请注意，您的 super 项目列出来自子模块的原始提交哈希的位置是:在每个提交中。您可以git checkout在您的 super 项目中进行一些提交，可能是某个分支的尖端。然后你可以进入子模块，选择一个你喜欢的提交，使用git checkout在那个子模块中——毕竟它是另一个 Git 克隆，所以你可以在那里执行任何 Git 命令——来检查所需的提交。然后，退出子模块(将目录更改回您的 super 项目)并运行 git add在子模块路径和 git commit记录新的所需哈希 ID。这个新的提交现在要求输入那个特定的哈希 ID。