1

我按照这篇博文中的步骤将一个 git repo 的内容复制到另一个。（它涉及创建一个远程，获取，然后使用带有路径名映射的读取树。）当我想合并后续更改时，问题就出现了。合并不知道路径名映射。有什么方法可以告诉它吗？

这是我将第二个 repo 的内容添加到更大 repo 的过程。

git remote add projB <github-remote-location>
git merge -s ours --no-commit projB/master
git read-tree --prefix=subdirB/ -u projB/master
git ci -m "merging projB into subdirB"

后来，有趣的结果是使用 git add 在旧的“projB”存储库中添加新的东西，然后在合并的存储库中运行：

git fetch projB
git pull projB SomeTag

这会导致新文件出现在未重新定位的位置。

4

1 回答 1

1

简短的回答是：

git pull -s subtree projB SomeTag

git默认情况下不跟踪移动或重命名。它似乎通过相似性捕获了一些信息，但在存储库的深处，它并没有保留该信息。此外，它无法用新文件猜测那种元数据。

您键入的命令不会对这些元数据做任何神奇的事情。他们最终所做的只是创建一个新的HEAD提交，该提交发生在：

  • 有projB/master一个额外的祖先（第2行）。基础祖先是你当前的 HEAD。在线性基线的通常情况下，所有提交都有一个祖先，除了没有任何祖先的初始提交。具有多个祖先的提交称为“合并”提交。

  • 包含所有projB/master包含的内容，向下移动到子目录subdirB（第 3 行）

但是在创建合并提交之后（第 4 行），就什么都不会记住了。尤其是哪些文件来自结果树中的哪个位置。

显然，该用例经常出现，以至于有人编写了一个subtree合并策略，该策略恰好是在寻找被合并的 ref 是否不适合其他地方而不是根。但是必须明确要求这种行为。

您链接到的博客文章碰巧提到了它，但它隐藏在最底部；作者没有在他的 TL;DR 中提醒它。您可以在 git 文档中找到更精简的故事版本，它也是 Pro Git 书中的一个部分。

于 2013-11-12T10:07:02.610 回答