git - 如何从不相关的存储库中 merge 历史

Question

我在 SVN 上有一个这样组织的旧项目:

• /一些/子目录/a/trunk/foo
• /一些/子目录/b/trunk/foo
• /一些/子目录/c/trunk/foo

我使用GitHub工具git-import-svn-raw将这三个仓库迁移到了三个Git仓库下:

• 一个.git
• b.git
• c.git

我用这个命令去掉了路径

git filter-branch --prune-empty --subdirectory-filter \
/some/sub-directories/a/trunk/foo master

现在我想将所有这三个项目的历史导入到同一个存储库中，我有三个目录 a、b、c。

bundle.git/
   a/
   b/
   c/

这个想法不是 merge 子树，而是将每个子目录的历史交织在一起。

这可能吗？

注意:将整个 SVN 存储库转换为单个存储库会更容易，但它不起作用。我在使用 git-import-svn-raw 工具时遇到了很多问题。同样的问题出现在 git svn clone --stdlayout 中，它需要一个存储库，但事实并非如此。我也尝试过 svn2git 但它也不起作用。

Answer 1

我建议不要使用“bundle”作为 repo 的名称，因为 bundle 对 git 有其他含义。为避免混淆问题，我将在整个回答中使用您的术语，但我会使用不同的名称。

因此很容易将所有提交放入同一个存储库。

cd bundle.git
git remote add a ../a.git
git remote add b ../b.git
git remote add c ../c.git
git fetch --all

现在你有像 remote/a/master, remote/b/master, remote/c/master 这样的引用。

A1 -- A2 -- A3 -- A4 <--(a/master)

B1 -- B2 -- B3 -- B4 <--(b/master)

C1 -- C2 -- C3 -- C4 <--(c/master)

(master)

请注意，我假设您从没有提交(“未出生”分支)的 master 开始，并且它在这里仍处于该状态。

接下来，获得包含 merge 内容的单个提交也不难。例如你可以这样做:

git reset --hard a/master
get merge --allow-unrelated-histories b/master
git merge --allow-unrelated-histories c/master

这会给你

               (a/master)
                   v
A1 -- A2 -- A3 -- A4 -- M1 ------------- M2 <--(master)
                       /                /
B1 --- B2 --- B3 --- B4 <--(b/master)  /
                                      /
C1 -------- C2 -------- C3 -------- C4 <--(c/master)

这个历史是完整和正确的，但历史提交没有交错，它们没有组合内容(TREE 对象)。因此，如果您查看 B3，您将看不到 a 或 c 在相应时间的样子。

这可能就足够了。 log 的输出将默认为按时间倒序排列，您可以提供排序选项来影响此历史记录的确切排序方式(请参阅 git log 文档)。但这不是你要求的......

所以下一步你可以

git rebase -i --root master

这将显示一个显示所有提交的“TODO”列表；但是您必须手动确定您希望它们交错的顺序。 (默认顺序遵循每个分支，一次一个。)所以这可能非常乏味。您可以使用 git log 输出找出正确的顺序，然后相应地重新安排 TODO 列表。

更新:我突然想到我应该添加一些关于 rebase 步骤的警告。

首先，上面只明确说明了 master 分支。当然，每个 repo 协议(protocol)都可以有额外的分支，您必须决定如何反射(reflect)这些分支。也许您会决定分支点(从分支可到达的 master 的第一次提交)应该保持不变，并且分支根本不会将来自其他 repos 的更改交织到其中(假设这不会' t 导致分支名称冲突)。或者，您可能会决定以某种方式组合每个源代码库中的相应分支。

其次，如果原始历史记录中存在 merge ，那么您必须决定如何在 rebase 中处理它们。如果 merge 包含冲突解决方案，或者是“邪恶的 merge ”(即引入相对于默认 merge 结果的更改的 merge )，这尤其是一个问题。上述过程将尝试生成单一的线性历史记录。如果这不是您想要的，那么就很难做到这一点，因为如果您告诉 rebase 保留 merge ，那么它也会将三个历史记录分开。 (此外，--preserve-merges 不能与 --interactive/-i 很好地混合。)

所以上面的方法适用于相对简单的历史，而对于更复杂的历史，它可能只是不切实际。