3

我的情况如下。

我克隆的项目最初是使用 Mercurial 进行版本控制的，我有一个原始 repo 的克隆及其所有历史。在某个时间点，该项目的所有者决定迁移到 GitHub，但在迁移过程中丢失了所有历史记录，因此这个新的仓库虽然是旧项目的延续，但实际上是从修订版 0 重新开始。

我想坚持使用 Hg，Hg-Git 显然可以让我从 Git 存储库中提取，但我不知道该怎么做是将 Hg 存储库的头部与 Git 存储库的尾部粘在一起所以我可以像以前一样继续拉下定期更新。Git 中与 Hg 存储库的头部匹配的实际提交不是第一次提交，所以它不是尾部的尖端。

我认为 hg convert 和 --splicemap 可能很有用，但我读的越多，它对我来说就越不像一个解决方案。

任何人都可以就我如何实现这一目标提供任何建议吗？

更新
只是为了任何可能尝试做类似事情的人的信息，我终于设法达到了我想要的结果，但这是一条漫长而曲折的道路，事实证明 hg convert 和 splicemap 毕竟是答案。

  1. 我使用 hg-git 插件从 Github 下载了 Git 存储库。
  2. 然后我将它克隆到一个新的 repo 并使用hg pull --force拉入相关但断开连接的 Hg repo 内容。
    所以现在我有一个包含 2 个不同的开发分支的仓库，就仓库而言，它们没有共同的祖先，我将把它称为hydra。
  3. 使用hg convert和splicemap我将历史记录中匹配点的分支加入到一个新的 repo 中，然后运行​​hg strip以摆脱杂散的不必要位。
  4. 然而，诀窍是原始的 Git 存储库将被更新，我希望能够将新的更改引入到这个联合的存储库中。
    解决方案？批处理文件。
    是的，你没听错，批处理文件。
    该解决方案实际上是一组 3 个，首先从 Github 拉到仅包含 Git 存储库的存储库。第二个从 Git 存储库中提取到 hydra 中（汞源不会改变，所以我不需要再次从中提取）。第三次重新运行hg convert命令，以便它使用来自 hydra 的新信息更新加入的 repo。

这很不愉快，它很冗长，而且设置起来有点像噩梦，但它现在运行得很干净，我的最终回购是一个可预测且合理的大小。

4

1 回答 1

3

从未尝试过，但也许在 bridge-repo 的 /.hg 中操作 git-mapfile 可以工作。我会这样尝试：

  1. 假设 Hg repo 的提示是 Git repo 的根。
  2. 仅通过 hg-git 将 Git 存储库克隆到根目录（这可以通过 Git 进行，对吗？）。
  3. 将原始 Hg 存储库中的所有提交拉入 hg-git 克隆。
  4. 去掉唯一的根，但记下这个根的完整哈希。
  5. 记下 Hg repo 提示的完整哈希（现在也是 hg-git 克隆的提示）。
  6. 编辑 /.hg/git-mapfile。它应该只包含一个条目，一侧有一个单独的根的哈希（应该在右边）。将此哈希替换为提示之一。不要替换另一边（左），因为它是对应 Git 提交对象的哈希。
  7. “汞拉”。如果理论成立，这会将新的 Git 节点添加到旧的 Hg 节点上。

可能完全是胡说八道，但至少 hg-git 的旧（“笨”）版本只是通过这个映射文件确定了必要的 git 对象。所以值得一试...

于 2013-06-26T18:20:55.713 回答