Git子模块更新：引用不是树...但提交IS在那里 [英] Git submodule update: reference is not a tree... but commit IS there

问题描述

首先：是的，我已经检查过这个线程里面 - 但我的情况是不同的。

这里有三个模块：

• 应用程序 A


• 其基础库 B （一个 A 的子模块）


• 组件 C （子模块 B ）

当尝试执行 git克隆 - 递归https：// url_of_A / ，当git试图获取 C ：

时，

 克隆到'path / of / C'... 
 [...] 
检查连通性... done 
致命：引用不是一棵树：92405dd9027a2d55d9dd6f5b26494eee0009e297 
无法检出在子模块路径 '92405dd9027a2d55d9dd6f5b26494eee0009e297' 
 '路径/到/ C' 
  

但是猜猜看，当我们做时没有错误， git clone --recursive https：// url_of_B / - 尽管签出的修订显然是相同的：

克隆到'path / of / C'中...
检查连通性... done
子模块路径'path / to / C'：检出'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 
  

• commit ac1fbbda201 ：子模块：不要从复制未知更新模式> .gitmodules


• 提交746593bdcaf ： refs ：删除未使用的功能 invalidate_ref_cache


>
• commit 927b26f87a5 ：子模块：不要使用<$ c打印状态输出$ c> ignore = all


• 提交4b054402833 ：避免子模块上的段错误*。path设置为空true


• 提交95c16418f03 ： RM ：删除 .gitmodules 从工作树中删除子模块的条目
  
• commit 0656781fadc ： mv ：更新 .gitmodules 移动子模块的路径条目


• 提交8745024422d ： parse_pathspec ：支持剥离/检查子模块路径

这些修补程序中有一个可以增强子模块功能的健壮性。

例如，msysgit问题你提到（ issue 99 ）可以通过提交4b054402833 。

First of all: yes, I've checked this thread inside out - but my situation is different.

We have three modules here:

• an application A
• its base library B (a submodule of A)
• a component C (a submodule of B)

When trying to do git clone --recursive https://url_of_A/, we get an error when git attempts to fetch 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'

But guess what, there's no error when we do git clone --recursive https://url_of_B/ - even though the revision to check out is clearly the same:

Cloning into 'path/of/C'...
Checking connectivity... done
Submodule path 'path/to/C': checked out '92405dd9027a2d55d9dd6f5b26494eee0009e297'

... even though remote pathes to C are the same!

What's even more puzzling: this behavior is observed at Windows 7/8 machines only (so far, at least). Windows Vista/XP machines somehow do the deep cloning with the same repositories without any glitches - and I really wonder how's THAT can be platform-dependent.

---

That's for the case, now the questions: 1) is there anyone with the same problem, and 2) what could be the workarounds? Note that all the components (A, B, and C) are not under our control, so 'switch to git-tree' and stuff like that just won't work, unfortunately.

解决方案

As a first (incomplete) answer, a lot of submodule corrections went between git 1.8.4 and 1.8.5.2:

C:\Users\VonC\prog\git\git>git log -Ssubmodule v1.8.4..v1.8.5.2

• commit ac1fbbda201: submodule: do not copy unknown update mode from .gitmodules
• commit 746593bdcaf: refs: remove unused function invalidate_ref_cache
• commit 04c1ee576ac: mv: Fix spurious warning when moving a file in presence of submodules
• commit 927b26f87a5: submodule: don't print status output with ignore=all
• commit 4b054402833: avoid segfault on submodule.*.path set to an empty "true"
• commit 95c16418f03: rm: delete .gitmodules entry of submodules removed from the work tree
• commit 0656781fadc: mv: update the path entry in .gitmodules for moved submodules
• commit 8745024422d: parse_pathspec: support stripping/checking submodule paths

It is possible one of those patches enhances the robustness of the submodule feature.
For instance, the msysgit issue you mention (issue 99) could be solved with commit 4b054402833.

这篇关于Git子模块更新：引用不是树...但提交IS在那里的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！