我有一对工作树与一些依赖关系。我猜，git子模块将强制执行以下操作:
- 在每个工作树的子目录中使用它(主)拥有每个工作树(从)的副本
- 主存储库复制从存储库的所有信息
我不介意仓库变大，但是有副本对我来说是不可接受的。这将迫使我重新组织所有的项目，这样副本就会被链接起来。此外，编辑错误的文件很容易导致混乱。
我有另一个想法:
- 每个主服务器存储所有从服务器的列表。
- 不需要master中的其他信息。
- 每次在主服务器上提交，都会在从服务器上创建一个"快照提交"。
- "snapshot-commit"是工作树当前状态的快照，它忽略了索引的当前状态(在丢弃一些未提交的更改之前，我已经使用了"snapshot-commits")。
- "快照提交"被收集在分支中，分支的名字来源于master的名字。提交消息包含主提交的哈希值。(恕我直言，这比成千上万的标签泛滥要好。)
- 检出正常工作，除非需要递归到slave。
我能看到的唯一问题是:
- 从服务器上的提交会累积，即使主服务器上的提交不存在也不会被删除。主服务器中的提交不是自包含的，您可以删除主服务器中引用的提交。但是我看不出这是偶然发生的可能性，所以我可以接受它。
- 我无法想象，其他git命令怎么能支持这个。不过，我还是可以接受的。
我在问是否有人已经实现了它(或者它是不是一个坏主意)。
我认为这是一个坏主意，因为它很奇怪，它会让你离开支持的路径。
首先澄清:当使用子模块时，"主"(引用)repo不会明显变大。它只存储一个存储库引用(可能是URL)和一个提交ID。但这似乎不是症结所在。
在处理这样的问题时，有三条基本的路径可以选择:
-
将所有内容放在一个存储库中。你是否已经十次说服自己，你真的需要把事情分开?请记住，您可以从一个回购开始，然后将其拆分。还请记住，git合并实际上是有效的，因此开发人员的争用不是那么大的问题。
-
使用一些外部包装管理系统。Git不是，也不假装是一个包管理器。您使用的平台很可能有一个支持更复杂依赖情况的包管理器。Maven, rubygems, npm, nuget…有很多。
-
在子目录中使用子模块'mounted'。
我不确定我是否在跟随你，因为父repo(你的"主")只存储对子模块(子repo在父repo中签出)的严格SHA1的引用。
父版本的大小完全不受影响。
子树合并策略(通过git子树更好地管理)会增加父repo的大小，但这(子树合并)不是你所说的。
子模块的另一个替代方案是git-slave (gits)，这有点像您想要实现的。