我建议不要使用“bundle”作为 repo 的名称，因为bundle 对 git 意味着其他东西。为避免混淆问题，我将在整个答案中使用您的术语，但我会使用不同的名称。
因此很容易将所有提交放到同一个 repo 中。
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 开始没有提交（“未出生”分支），并且它仍处于该状态。
接下来，获得包含组合内容的单个提交也不难。例如，您可以这样做：
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 都可以有额外的分支，您必须决定如何反映这些分支。也许您会决定分支点（来自分支的master 的第一个提交）应该保持不变，并且分支根本不会有来自其他存储库的更改交错进入它（假设这不会导致分支名称碰撞）。或者，也许您会决定以某种方式组合来自每个源代码库的相应分支。
其次，如果原始历史中有合并，那么您必须决定如何在变基中处理它们。如果合并包含冲突解决方案，或者是“邪恶的合并”（即引入相对于默认合并结果的更改的合并），这尤其是一个问题。上述过程将尝试生成单一的线性历史。如果这不是你想要的，那么很难做到这一点，因为如果你告诉rebase 保持合并，那么它也会保持三个历史分开。 （此外，--preserve-merges 不能很好地与 --interactive / -i 混合。）
因此，上述方法适用于相对简单的历史，而对于更复杂的历史，这可能不是一件实际的事情。