将Git垃圾收集提交到顶层存储库引用的子模块中？ [英] Will Git garbage-collect commit in submodule referred to by a top-level repository?

问题描述

假设：

  top.git 
└──sub.git => 75fc7 
  

• 顶层Git仓库 top .git 引用 sub.git 中的提交 75fc7 。


• 子模块Git仓库 sub.git 既没有分支也没有标签，导致提交 75fc7 （无法访问） 。
  

code> sub.git 最终会垃圾收集此提交 75fc7 因为没有东西可以达到它

AFAIK，Git子模块设计的方式是，例如， sub.git 无法确定它是任何其他存储库的子模块。换句话说，提交 75fc7 实际上是垃圾收集的候选者。如果可能忘记所需的提交，那么恢复所有子模块的状态将是不可靠的。

最后会被垃圾回收。

但是，不要忘记，要重复使用，其父库所引用的子模块也必须发布记录的SHA1（记录为 gitlink ，>

如果该SHA1未发布（推向上游回购仓库），则任何克隆无论如何，父回购将无法签出子模块。

这意味着子模块必须推送已记录的SHA1，从而使该SHA1被引用（通过分支或标签，如推入上游回购）

所以问题不在于垃圾收集器在这里，而仅仅是父级回购的能力来检验其子模块到右边的SHA1。

我的场景（没有明确提到问题）实际上是不同的和更具体的。如果提交实际上被推向上游 top.git 和 sub.git ？

然后，您无需等待 gc 删除不可访问的SHA1用于显示该问题。

如果发布的SHA1不再可参照，则表示 top.git 的任何克隆都不会能够在右边的SHA1签出 sub.git 子模块回购库（即使gc尚未运行），因为非引用的SHA1不会是无论如何， sub.git 克隆。

---

理解：上游回购 sub.git 不知道它被另一个上游回购用作子模块（如top.git）。

如果 sub.git 不包含右边的SHA1（由 top.git < （code> gc 或其他 rebase / push --force 或...） ， top.git 的克隆将无法将子模块恢复到正确的状态。

Let's say:

 top.git     
 └── sub.git => 75fc7

• The top-level Git repository top.git refers to commit 75fc7 in sub.git.
• The submodule Git repository sub.git has neither branches nor tags leading to commit 75fc7 (unreachable).

Will sub.git eventually garbage-collect this commit 75fc7 because nothing can reach it?

AFAIK, Git submodules designed the way that, in this example, sub.git is not able to establish the fact that it is a submodule of any other repository. In other words, commit 75fc7 is effectively a candidate for garbage collection. Then it would be unreliable to restore state of all submodules if they may "forget" required commits.

解决方案

Yes, the commit will be eventually garbage collected.

But don't forget that, to be reused, a submodule referenced by its parent repo must also published that recorded SHA1 (recorded as a gitlink, a special entry in the index of the parent repo).

If that SHA1 is not published (pushed to an upstream repo), then any clone of the parent repo would not be able to checkout the submodule anyway.
That means a submodule must push the recorded SHA1, which makes that SHA1 referenced (by a branch or tag, as pushed on the upstream repo)

So the issue is not so much the garbage collector here, but just the capability of a parent repo to checkout its submodule to the right SHA1.

My scenario (not explicitly mentioned in question) is actually different and more specific. What if the commits are actually pushed upstream for both top.git and sub.git?

Then you don't need to wait for a gc to remove a non-accessible SHA1 for the issue to manifest.
If the published SHA1 is no longer referable, it means any clone of top.git won't be able to checkout the sub.git submodule repo at the right SHA1 (even if gc hasn't run yet), because the non-referred SHA1 won't be part of the sub.git clone anyway.

---

The key point to understand: an upstream repo sub.git has no idea it is used as a submodule by another upstream repo (like top.git).

If sub.git does not include the right SHA1 (used by top.git) for any reason (gc or other rebase/push --force or ...), a clone of top.git will fail to restore the submodule to its proper state.

这篇关于将Git垃圾收集提交到顶层存储库引用的子模块中？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！