Git子模块的替代？

我有一些依赖工作的树。据我所知，git的子模块会执行以下操作：Git子模块的替代？

使用它（主）
主资料库复制从奴隶

我不介意回购越来越大，但拥有这些副本对我来说是相当不可接受的。这会迫使我重新组织所有的项目，这样副本就会被链接起来。而且，编辑错误的文件很容易导致混淆。

我已经有了另一个想法：

每个主存储其所有从站的列表。
主人不需要其他信息。
在主设备中进行每次提交时，都会创建从设备中的“snapshot-commit”。
“快照提交”是工作树当前状态的快照，它忽略了索引的当前状态（在丢弃一些未被改变的更改之前，我已经使用“快照提交”）。
“snapshot-commits”被收集到一个分支中，该分支的名字源自主人的名字。提交消息包含主提交的哈希。（恕我直言，这比淹没成千上万的标签要好。）
结帐工作正常，除非需要递归到奴隶。

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

在奴隶的提交将积累，永远不会被删除，即使主承诺不再存在。
在提交中的提交不是自包含的，您可以删除在主服务器中引用的提交。但我认为它不可能偶然发生，所以我可以忍受它。
我无法想象，其他git命令如何支持这一点。但再一次，我可以忍受它。

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

来源

2011-07-16 maaartinus

由于父母回购（您的“主”）只存储对子模块的严格SHA1（在父回购中签出的子回购）的引用，因此我不确定我是否关注您。
父回购的大小根本不受影响。

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

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

来源

2011-07-18 07:42:08 VonC

你的意思是，我错了我的句子“主存储库复制了所有从属的信息” ？这很可能，但是，我主要担心的是每棵主树中的每个从属树的副本是否存在（或者我错了吗？）。 – maaartinus

@maaartinus：有一个物理副本（因为它检出了一定的差异），但是所有的父回购保持是对检出的提交的引用。请参阅“子模块的真实性质”：http://stackoverflow.com/questions/1979167/git-submodule-update/1979194#1979194 – VonC

@maaartinus：但是，确实如此，每个父代回购将检出子模块，意思是所述子模块的几个副本将在任何给定时间存在。 – VonC

我认为这是一个坏主意，因为它很奇怪，它会带你走很多事情的支持路径。

首先澄清：当使用子模块时，“主”（参考）回购没有明显变大。它只存储一个存储库引用（可能是URL）和一个提交ID。但这似乎并不是这里的关键。

当这样的问题处理有三个基本路径3，你可以下去，

在单个存储库将所有的东西。你有没有说服自己10次，你真的需要把事情分开？请记住，您可以从一个回购开始，稍后再分解。另外请记住，git合并实际上是有效的，所以开发者争用并不是什么大问题。
使用一些外部包管理系统。 Git不是，也不会假装是包管理员。您使用的平台具有支持更复杂的依赖情况的软件包管理器的可能性很大。 Maven，rubygems，npm，nuget ...有很多。
在子目录中使用'mounted'子模块。

基本上，子模块应该是您处理自己的代码时的最后选择。它们非常适合与第三方库打交道，但最终会成为您自己代码的极大痛苦。再加上你提出的复杂解决方案，而且工作起来并不会很有趣。

来源

2012-08-02 00:20:07

感谢您的澄清和所有建议。我目前正在做的是使用多个eclipse项目，每个项目都有自己的git存储库。它们之间的依赖关系足够弱，以至于无法正常工作，而我之后的解决方案将解决唯一剩下的问题：不时发生引用的需要更改引用的repo中的更改。这使得在这样一个复杂的边界上及时回过头来，我所寻找的可以解决这个问题。我不经常需要它，所以任何可能出现的问题都很少见。安装的子模块可以做我所需要的... – maaartinus

在那里，做了那个，我真的不认为这是值得的努力。拥有一堆子模块就是其中的一种，听起来像是一个非常漂亮和优雅的想法（它就是这样），但日常使用只是一种痛苦。我不能鼓励你足够开始一个单一的回购。 –

我不同意@RussellMull，我想鼓励你不要把所有东西放在一个回购中。将太多的东西合并到一个存储库中是一种悲惨的经历，即使在我自己的项目中，我也是唯一一个处理它的项目。子模块对于这类事情并不是很好，但是它们比在一个git回购中将无关项目混合在一起要好得多。 –

Git子模块的替代？

回答

相关问题