Git子模块替代？

Question

我有一些工作树有一些依赖。 AFAIK，git子模块将强制执行以下操作：

• 使用它（主）在每个工作树的子目录中有每个工作树（slave）的副本
• 主存储库复制来自从属的所有信息

我不介意回购变大，但拥有副本对我来说是非常不可接受的。它会迫使我重新组织所有项目，以便将副本链接起来。此外，编辑错误的文件很容易发生，导致混淆。

我有另一个想法：

• 每个主人都存储其所有奴隶的清单。
• 主人不需要其他信息。
• 每次在master中提交时，都会创建slave中的“snapshot-commit”。
• “snapshot-commit”是工作树当前状态的快照，它忽略了索引的当前状态（在丢弃一些未经修改的更改之前，我已经使用了“snapshot-commits”）。
• “snapshot-commits”收集在一个分支中，该分支的名称来自主人的名字。提交消息包含主提交的哈希。 （恕我直言，这比成千上万的标签充斥更好。）
• 结帐工作照常，除非需要递归奴隶。

我能看到的唯一问题如下：

• 奴隶中的提交将累积，即使主提交不再存在也不会被删除。
• 在master中提交不是自包含的，你可以删除master中引用的提交。但我认为不可能偶然发生，所以我可以忍受它。
• 我无法想象，其他git命令如何支持这一点。但同样，我可以忍受它。

我在问是否有人已经实施了它（或者这是一个坏主意）。

Answer 1

我认为这是一个坏主意，因为它很奇怪，它会让你离开许多方面的支持路径。

首先澄清一下：当使用子模块时，'master'（引用）repo不会明显变大。它仅存储存储库引用（可能是URL）和提交ID。但这似乎不是这里的关键点。

在处理这样的问题时，你可以选择三条基本的路径：

1. 将所有内容放在一个存储库中。你有10次说服自己真的需要把事情分开吗？请记住，您可以从一个仓库开始，然后再拆分。还要记住，git merge实际上是有效的，因此开发人员争用并不是一个问题。

2. 使用一些外部包管理系统。 Git不是，也不是假装是包经理。您正在使用的平台有一个包管理器支持更复杂的依赖情况。 Maven，rubygems，npm，nuget ......有很多。

3. 在子目录中使用“已安装”的子模块。

基本上，在处理您自己的代码时，子模块应该是您的最后选择。它们非常适合处理第三方库，但最终会成为您自己代码的王室痛苦。除此之外，您还提出了一个复杂的解决方案，而且工作起来不会很有趣。

Answer 2

我不确定我是否关注你，因为父回购（你的“主人”）只存储对子模块的紧密SHA1的引用（在父回购中检出的子回购）。
父回购的大小根本不受影响。

subtree merge strategy（better managed though git subtree）会增加父回购的大小，但是（子树合并）并不是你所说的。

子模块的另一种替代方法是git-slave (gits)，这有点像你想要实现的。