使用Git复制子模块 [英] Duplicate submodules with Git
问题描述
我在Git中有一个项目，它有几个子模块，我需要下载这些子模块并使用可用的文件才能使用主项目，并且为了使子模块工作，我需要他们自己的子模块等等。所以设置这个我递归初始化子模块使用 git submodule update --init --recursive 。
但是，我注意到我的许多子模块都有共享依赖关系，看起来像伪代码（ alpha - > beta ）表示 alpha 有子模块 beta ）
my项目 - >子模块a - >子模块m
- >子模块b - >子模块m
- >子模块n - >子模块x
- >子模块c - > submodule x
我的问题是：是否有任何方法可以避免使用只有git的重复， （至少一份）每个子模块的文件？
我可以想象一个符号链接的解决方案，但如果git为我处理了这个问题，那么最好是这样我不知道在更新子模块时是否自己插入符号链接会导致问题。
理想情况下，我很乐意将其简化为：
我的项目 - >子模块a - >符号链接（子模块m）
- >子模块b - >符号链接（子模块m）
- >符号链接（子模块n）
- >子模块c - >符号链接（子模块x）
- >子模块m
- >子模块n - >符号链接（子模块x）
- >子模块x
预先感谢您的任何建议！
这不是git中的内容，但是您可以像使用符号链接一样使用它。你可能想看看 git new-workdir （来自git的contrib目录），它基本上做到了这一点。它不知道与子模块有什么关系，但子模块不知道它是子模块 - 它是知道这些东西的父回购。我还没有尝试过，但我相当肯定你可以像这样使用它：
＃先删除目标（new-workdir将拒绝覆盖）
rm -rf submodule_b / submodule_m
$ b $（原始回购）（符号链接回购）
git new-workdir submodule_a / submodule_m submodule_b / submodule_m
它通过symlinking基本上处理所有.git目录;值得注意的是没有符号链接的是 HEAD ;这两个目录可以检出不同的东西，但共享相同的参考和对象。
从这里你应该很好。在supermodule中运行 git submodule 命令时，它只会进入子模块并在那里运行适当的命令，这些命令都将按预期工作。
通常需要注意的一点是，它们共享同一组分支，所以如果它们都检出了相同的分支，并且您承诺一个，另一个会变得不同步。子模块通常不会成为问题，因为它们基本上总是处于分离的HEAD状态，除非您介入。
I have a project in Git that has several submodules, and I need those submodules to be downloaded and the files available in order to use the main project, and in order for the submodules to work I need their own submodules to be available etc. So to set this up I recursively initialise the submodules using git submodule update --init --recursive.
However, I've noticed that many of my submodules have shared dependencies, looking something like this in pseudocode (alpha -> beta represents that alpha has the submodule beta)
my project -> submodule a -> submodule m
-> submodule b -> submodule m
-> submodule n -> submodule x
-> submodule c -> submodule x
My question is: is there any way of avoiding this duplication using only git, while still having (at least one copy of) the files for each submodule?
I can imagine a solution with symlinks, but it would be preferable if git handled this for me, and I'm not sure whether putting in the symlinks myself would cause problems when updating the submodules.
Ideally I'd love to simplify it down to:
my project -> submodule a -> symlink(submodule m)
-> submodule b -> symlink(submodule m)
-> symlink(submodule n)
-> submodule c -> symlink(submodule x)
-> submodule m
-> submodule n -> symlink(submodule x)
-> submodule x
Thanks in advance for any suggestions!
This isn't built into git, but you can definitely do it with symlinks like you say. You might want to have a look at git new-workdir (from git's contrib directory), which does essentially this. It's not aware of anything to do with submodules, but a submodule doesn't know it's a submodule - it's the parent repo that knows about that stuff. I haven't tried this, but I'm fairly certain you could use it something like this:
# remove the target first (new-workdir will refuse to overwrite)
rm -rf submodule_b/submodule_m
# (original repo) (symlinked repo)
git new-workdir submodule_a/submodule_m submodule_b/submodule_m
It works by symlinking essentially all of the .git directory; the notable thing that isn't symlinked is HEAD; the two directories can have different things checked out, but share the same refs and objects.
From here you should be good. When you run a git submodule command in the supermodule, it just goes into the submodules and runs appropriate commands there, which will all work as expected.
The one thing you usually need to be aware of with symlinked repos like this is that they share the same set of branches, so if they both have the same branch checked out, and you commit to it in one, the other will become out of sync. With submodules this generally won't be a problem, though, since they're essentially always in detached HEAD state unless you intervene.
这篇关于使用Git复制子模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
