合并同一个项目的两个git仓库，链接文件历史

Question

我有一个很久以前就开始的项目，并做出了许多承诺。然后该项目被放弃了大约两年，在此期间我忘记了我一直在项目上使用 git 版本控制。我拿起它，将所有文件复制到一台新机器上，并启动了一个新的 git 存储库，其中包含大约 100,000 行代码和数十个文件，现在它拥有自己的冗长提交历史。我最近重新发现了旧的 repo，并尝试将两个 repo 的提交历史合并在一起，using the instructions here.

但是，结果不完整。如果我查看 github 上的提交历史记录，来自旧存储库和新存储库的提交是完整的，但是每个单独的文件历史记录不会延伸回旧存储库的一系列提交，仍然显示它们只是在创建时提交期间创建的的新存储库。当我手动复制所有内容以启动新 repo 时，一些未传输的文件根本不显示。

自旧存储库历史结束以来，项目的文件结构和命名约定发生了显着变化，并且某些文件关联可能并不明显。如果我必须手动将旧的与新的链接一次，我可以这样做，但自动解决方案会更好。

Answer 1

我假设您已按照您所链接问题的最佳答案中的步骤进行操作。对于这种情况，这些不是最好的步骤。

您的项目有两个历史片段。如果我们假设第一段有提交

A -- B -- C <--(master)

第二段有提交

D -- E -- F <--(master)

那么一个完整的历史会像预期的那样运行

A -- B -- C -- D' -- E' -- F' <--(master)

（关于符号的说明：我在合并历史等中已将 D 替换为 D'。其原因可以说是技术性的，可能并不立即重要；总而言之，它只是意味着提交身份，D' 与D 不同，因为D' 有C 作为父级，而D 没有。但是字母保持不变，以表明D' 代表相同的状态代码 - 即相同的内容或TREE - 与D。）

您链接的答案并没有做到这一点。它满足了两个最基本的目标——将提交放在一个 repo 中，并将它们组合成一个图表——但它不满足最有价值的一个目标：为它们制作一个连贯的历史。相反，它会给你

   A -- B -- C
              \
D -- E -- F -- f*

其中f* 是一个合并提交（即具有多个父项的提交），其内容与F 匹配，但也将C 列为其历史记录的一部分。

问题在于C 不是 然后被识别为Ds 历史的一部分。事实上，git 的默认历史过滤规则（例如用于日志输出）将完全排除 A、B 和 C，因为从 git 的角度来看，没有它们可以解释代码的状态。

（关于您的问题，当前大多数 cmets 都在谈论相似性启发式等问题，但在我看来，这些 cmets 是由没有真正仔细研究您所遵循的步骤的人编写的。 )

有几种不同的方法可以达到所需的状态。如果这是一个只有你使用的 repo，或者如果你可以与所有 repo 用户协调进行历史重写，那么“re-parenting”操作将是一个很好的解决方案。这是一个永久修复，将创建一个无缝的历史；但是，因为它会改变当前 repo 分支的历史，所以与任何其他用户的协调很重要。重写共享历史的问题一般在 git rebase 文档中关于“从上游 rebase 恢复”一节中描述。​​

另一种选择是使用git replace。这样做的好处是它不是历史重写，但它确实存在一些已知问题，并且需要在每个克隆中进行一些特殊设置。 （如果设置没有完成，这只是意味着特定的克隆没有看到完整的历史记录。）

这里有一篇文章讨论了实现这些方法的方法：Git: Copy history of file from one repository to another

还有其他变体，很难说哪种最适合您的情况。如果您想更广泛地探索这些可能性，您可以查阅 git filter-branch 和 git replace 的文档。