首先：是的，我已经从内到外检查了该线程-但是我的情况有所不同。
这里有三个模块：
AB（的子模块A）C（的子模块B）尝试做时git clone --recursive https://url_of_A/，当git尝试获取时，我们得到一个错误C：
Cloning into 'path/of/C'...
[...]
Checking connectivity... done
fatal: reference is not a tree: 92405dd9027a2d55d9dd6f5b26494eee0009e297
Unable to checkout '92405dd9027a2d55d9dd6f5b26494eee0009e297'
in submodule path 'path/to/C'
但是，请猜怎么着，我们做的时候没有错误git clone --recursive https://url_of_B/-尽管要签出的修订版显然是相同的：
Cloning into 'path/of/C'...
Checking connectivity... done
Submodule path 'path/to/C': checked out '92405dd9027a2d55d9dd6f5b26494eee0009e297'
...即使远程路径C相同！
更令人困惑的是：仅在Windows 7/8计算机上（至少到目前为止）才观察到此行为。Windows Vista / XP计算机以某种方式对相同的存储库进行了深层克隆，而没有出现任何小故障-我真的很想知道它如何与平台相关。
就是这种情况，现在的问题是：1）是否有人遇到相同的问题，以及2）可能的解决方法是什么？请注意，所有组件（A，B和C）都不在我们的控制之下，因此不幸的是，“切换到git-tree”之类的东西将无法工作。
作为第一个（不完整的）答案，许多子模块更正在git 1.8.4和1.8.5.2之间进行：
C:\Users\VonC\prog\git\git>git log -Ssubmodule v1.8.4..v1.8.5.2
submodule不要从以下位置复制未知更新模式.gitmodulesrefs：删除未使用的功能invalidate_ref_cachemv修复存在子模块时移动文件时的虚假警告ignore=allrm删除.gitmodules从工作树中删除的子模块的条目mv更新已.gitmodules移动子模块的路径条目parse_pathspec：支持剥离/检查子模块路径这些补丁之一可能会增强子模块功能的鲁棒性。
例如，您提到的msysgit问题（问题99）可以通过commit 4b054402833解决。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句