Git与Mercurial仓库的互操作性

Hg-Git Mercurial插件。我自己还没试过，但可能值得一试。

你可以尝试hg2git，这是一个python脚本，是快速导出的一部分，你可以在http://repo.or.cz/w/fast-export.git找到它。

不过，您需要安装mercurial。

因为hg-git是一个__abc0方式的桥，它还允许你将变更集从Git推到Mercurial。

你应该能够使用hg-git。

hg clone <hg repository>

编辑~/.hgrc并添加:

[extensions]
hgext.bookmarks =
hggit =

创建一个书签，这样你就会在git中有一个master:

cd <repository>
hg bookmark -r default master

在库中编辑.hg/hgrc并添加:

[git]
intree = true

现在你可以创建git存储库:

hg gexport

您可以使用生成的目录作为git克隆。从mercurial提取如下:

hg pull
hg gexport

然后推到mercurial:

hg gimport
hg push

(是的，你需要在这个工作流中使用hg，但你的黑客将全部在git中)

P.S.如果你对这个工作流程有问题，请提交一个bug。

关于这个主题的一个小问题/警告:

我尝试用hg克隆一个稳定的linux内核存储库。这些存储库在git中维护，通常有大量的文件。

它非常慢。花了我2天完全克隆而且更新一个工作副本。

2012年6月更新。目前，当开发者想从Git端工作时，Git/Hg的互操作性似乎有以下几种方法:

1. 安装Mercurial和< >强hg-git扩展< / >强. conf文件。你可以使用包管理器或easy_install hg-git来实现后者。然后确保你的~/.hgrc中有以下文件:

   [extensions]
   hggit =
   

你可能会在这里看到一些关于指定bookmarks扩展的引用，但它自v 1.8以来就已经内置到Mercurial中了。这里是关于在Windows上安装hg-git的一些提示。

一旦你有了hg-git，你就可以使用类似Abderrahim Kitouni在上面发帖的命令。该方法自2009年以来一直是改进和调整，并且有一个友好的包装器:< >强git-hg-again < / >强。这将同时使用顶层目录作为Mercurial和Git的工作目录。它创建了一个Mercurial书签，它与Mercurial存储库中的default(未命名)分支的顶端保持同步，并从该书签更新本地Git分支。

2. < >强git-remote-hg < / >强是一个不同的包装器，同样基于Mercurial hg-git扩展。这还使用了git-remote-helpers协议(因此得名)。它只对Git工作目录使用顶层目录;它保持其Mercurial存储库裸露。它还维护了第二个纯Git存储库，以使Git和Mercurial之间的同步更安全，更符合Git的习惯。

3. < >强git-hg < / >强脚本(以前维护为在这里)使用了不同的方法，基于< >强fast-export项目< / >强中的hg-fast-export。与方法2一样，这也保留了一个纯Mercurial存储库和一个额外的纯Git存储库。

对于拉取，该工具忽略Mercurial书签，而是将每个已命名的Mercurial分支导入Git分支，并将默认的(未命名的)Mercurial分支导入master。

一些评论讨论这个工具只是hg->git，但它声称已经在2011年12月7日合并到git->hg push支持中。不过，正如我在这些工具的回顾中解释的那样，这个工具试图实现推送支持的方式似乎是不可行的。

4. 还有另一个项目叫做git-remote-hg。与上面列出的版本不同，这个版本不依赖hg-git，而是直接访问Mercurial Python API。目前，使用它还需要一个补丁版本的git。我还没试过。

5. 最后，< >强裁缝< / >强是一个在各种不同的vcs之间增量转换的项目。听起来这方面的发展不会继续下去。

前三种方法看起来微不足道，足以说服我去调查。我需要在某些方面调整它们以使它们能够在我的设置上运行，并且我看到了一些进一步调整它们以改进它们的方法，然后我进一步调整它们以使它们的行为更加相似，以便我能够更有效地评估它们。然后我想其他人可能也想做这些调整，做同样的评估。所以我有制作一个源包，它将使您能够安装我的前三个工具中的任何一个版本。它还应该负责安装所需的hg-fast-export块。(你需要自己安装hg-git。)

我鼓励你尝试一下，自己决定哪种效果最好。我很高兴听到这些工具坏了的情况。我将努力使它们与上游的更改保持同步，并确保上游作者意识到我认为有用的调整。

正如我上面提到的，在评估这些工具时，我得出的结论是git-hg只能用于从Mercurial中提取，而不能用于推送。

相关的，这里有一些Git和Mercurial之间有用的比较/翻译手册，在某些情况下针对已经了解Git的用户:

• Mercurial for Git users
• Git和Mercurial -比较和对比
• Mercurial和Git的区别是什么
• Mercurial和Git:一个技术上的比较
• Git hg rosetta stone
• 自制代码:Mercurial .
• Francisoud的博客:Git vs Mercurial (hg)
• Git vs Mercurial

我已经从https://github.com/cosmin/git-hg使用git-hg取得了巨大的成功(也需要安装hg)。它支持取，拉和推，对我来说比hg-git更稳定(类似的功能从hg到git)。

有关用法示例，请参阅https://github.com/cosmin/git-hg#usage。用户界面非常类似于git-svn。

git-hg为每个克隆hg repo需要额外的磁盘空间。实现使用完整的mercurial克隆，一个额外的git裸克隆和实际的git回购。所需的磁盘空间大约是正常git使用量的3倍。额外的副本存储在工作目录的.git目录下(或通常由GIT_DIR指向的位置)。

git-hg试图解决的基本问题是git和hg特征之间没有1:1的映射。最大的问题是git分支和Hg未命名分支、Hg命名分支和hg的书签之间的阻抗不匹配(对git用户来说，所有这些看起来都很像分支)。一个相关的问题是hg尝试在版本历史中保存原始的已命名分支名称，而git在默认情况下只将分支名称添加到模板提交消息中。

你可以决定选择的解决方案是否适合你的需要。

git-hg使用的解决方案是丢弃所有hg书签并将命名分支转换为git分支。此外，它将git主分支设置为默认的未命名hg分支。

有一个新的git-remote-hg提供本地支持:

Git中对Mercurial和Bazaar的桥接支持

只需要将git-remote-hg复制到你的$PATH，使其可执行，就是这样，没有依赖关系(除了Mercurial):

git clone hg::https://www.mercurial-scm.org/repo/hg/

您应该能够从它中推入和拉出，就像它是一个原生Git存储库一样。

当您推送新的Git分支时，将为它们创建Mercurial书签。

更多信息请参见git-remote-hg维基。

我已经在马特的hg回购上尝试了cosmin的git-hg和abourget的git-hg-again，似乎后者尊重合并的顺序，前者有点随机。你可以从下面的截图中看到。

由cosmin的git-hg导入的mutt的合并历史图:

由abourget的git-hg-again导入的mutt的合并历史图:

hgk在mutt's hg库上绘制的实际历史图:

正如你可以从上面看到的，abourget的git-hg-again的第二个图非常接近原始的hgk图，实际上反映了mutt的真实工作流程。

我再次发现git-hg的一个缺点是它没有添加一个'hg'远程，而是将所有的引用作为本地标签导入，git-hg有一个很好的'hg'远程表示上游hg repo。

双向hg-git(和git-git, hg-hg)同步也可以通过服务Git-hg镜子实现。它在幕后使用hg-git(以及其他)，其代码也是开源的。

免责声明:我来自它背后的公司。

2021年的最新答案似乎是git cinnabar，例如Firefox使用。

本页上建议的其他脚本要么没有维护，要么需要过时的软件才能运行(通常是python 2.7)。相比之下，cinnabar可以使用python 3.5+，并且至少可以维护到本文撰写之日。

一旦安装了朱砂，你可以通过hg::前缀直接克隆mercurial存储库:

git clone hg::https://hg.mozilla.org/mozilla-unified

或添加或设置一个远程到

git remote set-url origin hg::https://hg.mozilla.org/mozilla-unified
git fetch origin

你可以按下多变的遥控器。