Git与Mercurial Repository的互操作性
我在Mac上使用GIT。 说够了。 我有工具，我有经验。 我想继续使用它。 这里没有战争
问题总是与互操作性有关。 大多数人使用SVN，这对我很好。 Git SVN开箱即用，并且是一个没有装饰的解决scheme。 人们可以继续高兴地使用SVN，我不会失去我的工作stream程，也不会失去我的工具。
现在…有些人与Mercurial一起。 对他们很好：他们有他们的理由。 但我找不到任何GIT HG。 我不想切换到HG，但我仍然需要与其存储库进行互操作。
你们中的任何人都知道这个简单的解决scheme？
从2012年6月开始更新。当开发人员想要从git工作时，目前似乎有以下Git / Hg互操作性的方法：
-
安装Mercurial和hg-git扩展 。 你可以使用你的软件包pipe理器或
easy_install hg-git来完成后者。 然后确保以下内容在你的〜/ .hgrc中：[extensions] hggit =您可能会看到一些参考资料，这里也提到了指定
bookmarks扩展的方法，但自1.8版本以来已经内置到Mercurial中。 这里有一些关于在Windows上安装hg-git的提示 。一旦你有了gg -git，你可以像上面提到的Abderrahim Kitouni一样使用命令。 这个方法自2009年以来已经完善和调整 ，并且有一个友好的包装： git-hg-again 。 这将同时使用顶级目录作为Mercurial和Git的工作目录。 它创build一个Mercurial书签，它与Mercurial存储库中的
default（未命名）分支的提示保持同步，并从该书签更新本地Git分支。 -
git-remote-hg是一个不同的包装，也基于Mercurial的
hg-git扩展。 这另外使用了git-remote-helpers协议（因此它的名字）。 它只使用顶级目录作为Git工作目录; 它保持其Mercurial存储库裸露。 它还维护第二个裸Git存储库，使Git和Mercurial之间更安全，更习惯地gitlike。 -
git-hg脚本（以前保存在这里 ）使用一种不同的方法，基于快速导出项目中的
hg-fast-export。 像方法2一样，这也保留了Mercurial仓库和一个额外的裸Git仓库。对于拉取，这个工具忽略了Mercurial书签，而是将每个命名的Mercurial分支导入到Git分支中，而默认的（未命名的）Mercurial分支导入到主分支中。
有些评论认为这个工具只是hg-> git，但是它声称已经在2011年12月7日的git-> hg推送支持中被合并了。正如我在这些工具的回顾中解释的那样，这个工具试图实现推支持似乎不可行。
-
还有另外一个名为git-remote-hg的项目 。 与上面列出的版本不同，这个版本不依赖于hg-git，而是直接访问Mercurial Python API。 目前，使用它也需要一个补丁版本的git。 我还没有尝试过。
-
最后， 裁缝是一个项目，可以在各种不同的VCS之间进行递增的转换。 听起来这样的发展将不会激烈地继续下去。
前三种方法看起来足够轻以说服我去调查。 我需要在某些方面调整它们以使它们在我的设置上运行，并且我看到了一些方法来进一步调整它们以改进它们，然后我进一步调整它们以使它们更像彼此的行为，以便我可以评估他们更有效。 然后我觉得其他人也可能喜欢这些调整，做同样的评价。 所以我已经做了一个源代码包 ，使您能够安装我的前三个工具的任何版本。 它也应该照顾安装所需hg-fast-export件。 （您需要自行安装hg-git 。）
我鼓励你尝试一下，自己决定什么效果最好。 我会很高兴听到这些工具中断的情况。 我会尽量保持它们与上游变化同步，并确保上游作者意识到我认为有用的调整。
正如我上面提到的，在评估这些工具时，我得出的结论是， git-hg只能用于从Mercurial中提取，而不能用于推送。
相关的，下面是Git和Mercurial之间的一些有用的比较/翻译手册，在某些情况下针对已经了解Git的用户：
- Git用户的Mercurial
- Git与Mercurial – 比较与对比
- Mercurial和Git有什么区别？
- Mercurial和Git：技术比较
- Git hg rosetta stone
- 自制编码：水银
- Francisoud的博客：Git vs Mercurial（hg）
- Git与Mercurial
有一个新的git-remote-hg提供本机支持：
Meritial和Bazaar的Git支持
只要将git-remote-hg复制到你的$ PATH中，使其成为可执行文件即可，没有任何依赖关系（Mercurial除外）：
git clone hg::https://www.mercurial-scm.org/repo/hg/
你应该能够像从本地的Git仓库那样推拉它。
当你推新的Git分支，Mercurial书签将为他们创build。
有关更多信息，请参阅git-remote-hg wiki 。
你应该可以使用hg-git 。
hg clone <hg repository>
编辑~/.hgrc并添加：
[extensions] hgext.bookmarks = hggit =
创build一个书签，所以你将有一个在Git的master ：
cd <repository> hg bookmark -r default master
编辑.hg/hgrc中的.hg/hgrc并添加：
[git] intree = true
现在你可以创buildgit仓库了：
hg gexport
并且可以使用生成的目录作为git克隆。 从mercurial拉动将是：
hg pull hg gexport
并推动着mercurial：
hg gimport hg push
（是的，你需要在这个工作stream程中使用hg，但是你的黑客将全部在git中）
PS如果您在此工作stream程中遇到问题，请提交错误报告。
您可以尝试hg2git ，这是python脚本，是快速导出的一部分，您可以在http://repo.or.cz/w/fast-export.gitfind它。;
你需要安装mercurial。
由于hg-git是一个双向桥梁，它也将允许您将变更集从Git推送到Mercurial。
Hg-Git Mercurial Plugin 。 还没有尝试过，但可能值得一试。
我从https://github.com/cosmin/git-hg获得了;git-hg巨大成功（也需要安装hg ）。 它支持取，拉和推 ，对我来说比hg-git （从hg到git类似的function）更稳定。
有关使用示例，请参阅https://github.com/cosmin/git-hg#usage 。 用户界面非常类似于git-svn 。
git-hg需要为每个克隆的hg repo额外的磁盘空间。 该实现使用完整的mercurial克隆，一个额外的git裸克隆和实际的git回购。 所需的磁盘空间大约是正常的git only用法的3倍。 额外的副本存储在您的工作目录的.git目录下（或像往常一样由GIT_DIR指向的位置）。
注意： git-hg试图解决的基本问题是git和hg之间没有1：1的映射关系。 最大的问题是git分支和hg未命名分支与hg命名分支和hg书签之间的阻抗不匹配（所有这些看起来很像分支给git用户）。 一个相关的问题是， hg尝试保存版本历史logging中的原始命名分支名称，而不是git，默认情况下只将分支名称添加到模板提交消息中。
任何声称在git和hg之间build立可互操作桥梁的工具都应该解释它将如何处理这种阻抗匹配。 您可以决定select的解决scheme是否适合您的需求。
git-hg使用的解决scheme是放弃所有的hg书签并将命名分支转换为git分支。 另外它将git master分支设置为默认的未命名的hg分支。
已经试过hggit。 为我工作，因为我必须应付git'ers和hg'ers的工作。 特别是评论这是伟大的。
关于该主题的小问题/警告：
我试图用hg克隆一个稳定的linux内核仓库。 这些存储库保存在git中，并且通常包含大量的文件。
这是非常缓慢的。 花了我2天来完全克隆和更新工作副本。
我已经尝试了cosmin的git-hg和abourget的git-hg-再次在mutt的hg repo上 ，似乎后来尊重merge的顺序很好，前者有点随意。 你可以从下面的截图中看到。
由cosmin的git-hg导入的mutt合并历史logging图：
再次通过abourget的git-hg导入的mutt合并历史logging图：
hgk在mutt的hg仓库中绘制的执行历史图：
从上面可以看到， abourget的git-hg的第二个graphics与原始的hgkgraphics非常接近，实际上反映了mutt的真实工作stream程。
我发现git-hg的一个缺点是它没有添加'hg'remote，而是将所有的引用作为本地标签导入，git-hg有一个很棒的'hg'remote代表上游的hg repo。
这是一个古老的问题，但我认为值得一提的是：双向的gg-git（和git-git，hg-hg）同步也可以通过服务Git-hg Mirror来实现 。 它使用hg-git（其他）在幕后，其代码也是开源的。
免责声明：我来自背后的公司。
