Git 作为 mercurial 客户端？为什么没有 git-hg？

Git as mercurial client? Why no git-hg?

提问by Kai Inkinen

This is a question that's been bothering me for a while. I've done my homework and checked stackoverflow and found at least these two topics about my question: Git for Mercurial like git-svnand Git interoperability with a Mercurial repository

这是一个困扰我一段时间的问题。我已经完成了我的作业并检查了 stackoverflow 并找到了关于我的问题的至少这两个主题： Git for Mercurial like git-svn和 Git interoperability with a Mercurial repository

I've done some serious googling to solve this issue, but so far with no luck. I've also read the Git Internalsbook, and the Mercurial Definitive Behind the Scenesto try to figure this out. I'm still a bit puzzled why I haven't been able to find any suitable git-hg type of a tool.

我已经做了一些认真的谷歌搜索来解决这个问题，但到目前为止还没有运气。我还阅读了Git Internals一书和Mercurial Definitive 幕后花絮来尝试解决这个问题。我仍然有点困惑为什么我一直无法找到任何合适的 git-hg 类型的工具。

From my perspective git-svn is one of the main features, why I've chosen to use git over mercurial also at work. It allows me to use a workflow I like, and nobody else needs to bother, if they don't care. I just don't see the point in using the intermediate hg repo to convert back and forth, as suggested in one of the chains.

从我的角度来看，git-svn 是主要功能之一，为什么我选择在工作中使用 git 而不是 mercurial。它允许我使用我喜欢的工作流程，如果他们不在乎，没有人需要打扰。我只是没有看到使用中间 hg repo 来回转换的意义，正如其中一个链中所建议的那样。

So anyway, from what I've read hg and git seem very similar in conceptual design. There are differences under the hood, but none of those should prevent creating a git client for hg. As it seems to me, remote tracking branches and octopus merges make git even more powerful than hg is.

所以无论如何，从我读过的内容来看，hg 和 git 在概念设计上似乎非常相似。引擎盖下存在差异，但这些都不应该阻止为 hg 创建 git 客户端。在我看来，远程跟踪分支和章鱼合并使 git 比 hg 更强大。

So, the real question, is there any real reason why git-hg does not exist (or at least is very hard to find)? Is there some animosity from git users (and developers) towards their hg counterparts that has caused the lack of the git-hg tool? Do any of you have any plans to develop something like this, and go public with it? I could volunteer (although with very feeble C-skills) to participate to get this done. I just don't possess the full knowledge to start this up myself.

那么，真正的问题是，为什么 git-hg 不存在（或者至少很难找到）有什么真正的原因吗？git 用户（和开发人员）是否对他们的 hg 同行存在一些敌意，导致缺乏 git-hg 工具？你们有没有计划开发这样的东西并公开它？我可以自愿（尽管 C 技能非常薄弱）参与完成这项工作。我只是不具备自己开始这项工作的全部知识。

Could this be the tool to end all DVCS wars for good?

这能成为永久结束所有 DVCS War的工具吗？

采纳答案by Tom Willis

hg-gitand the author's Pycon presentationexplaining his take on the situation.not sure if you came across these while googling but they answered my questions.

hg-git和作者的Pycon 演示文稿解释了他对这种情况的看法。不确定您在谷歌搜索时是否遇到过这些，但他们回答了我的问题。

回答by akaihola

I haven't tried this, but there seems to be a git-hgproject. The project describes itself on the page and the README as:

我没有试过这个，但似乎有一个git-hg项目。该项目在页面和自述文件中描述为：

A git-hg utility for checking out and tracking a mercurial repo.

A set of scripts for checking out and tracking a mercrial [sic] project.

用于检查和跟踪 mercurial 回购的 git-hg 实用程序。

一组用于检查和跟踪mercrial [sic] 项目的脚本。

It doesn't seem to work bi-directionally though (see issue tracker).

虽然它似乎不能双向工作（请参阅问题跟踪器）。

回答by Max

There is another project to realize this: git-remote-hg. Actually two of them, a native one (see https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg) and another one based upon hg-git (see https://github.com/rfk/git-remote-hg). The former is much faster than the latter, but still incomplete and under development.

还有另一个项目可以实现这一点：git-remote-hg。实际上有两个，一个是原生的（参见https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg）和另一个基于 hg-git（参见https://github.com）。 com/rfk/git-remote-hg）。前者比后者快得多，但仍不完整且正在开发中。

There are actually git remote helpers (as these tools are called) for other systems, either already there or under development; this includes support for Subversion, CVS, bazaar, and even MediaWiki.

实际上有其他系统的 git 远程助手（因为这些工具被称为），要么已经存在，要么正在开发中；这包括对 Subversion、CVS、bazaar 甚至 MediaWiki 的支持。

Cloning a Mercurial repository via git then is simply done like this:

通过 git 克隆一个 Mercurial 存储库，然后简单地完成如下：

git clone hg::https://hg.example.com/some-mercurial-repo

UPDATE: By now there is a third one, also "native", namely the one by Felipe which he mentions in his answer here. This one looks like it soon might be part of the git 'contrib' dir: https://github.com/felipec/git-remote-hgIt works without requiring patches to git itself, though some patches to git (under review now) can be applied to improve the overall user experience.

更新：现在有第三个，也是“本地的”，即 Felipe 在他的回答中提到的那个。这个看起来很快就会成为 git 'contrib' 目录的一部分：https: //github.com/felipec/git-remote-hg它不需要修补 git 本身就可以工作，尽管有一些 git 补丁（正在中） ) 可用于改善整体用户体验。

UPDATE 2: And now there is yet another contender, this one being under quite active development, and based on felipe's code: https://github.com/buchuki/gitifyhg-- it works quite well for me so far, but there are still some rough spots.

更新 2：现在还有另一个竞争者，这个竞争者正在积极开发中，基于 felipe 的代码：https: //github.com/buchuki/gitifyhg——到目前为止它对我来说效果很好，但是有还是有些粗糙的地方。

UPDATE 3: Both gitifyhg and Felipe's git-remote-hg are currently not actively maintained. For the time being, I made a form of Felipe's code with some fixes, including some to make it work with recent Mercurial versions. You can get it from https://github.com/fingolfin/git-remote-hg. Finally, therere is yet another recent contender, git-cinnabar, using a completly different approach internally (though if you don't care about that, using it is more or less the same as for the other git-remote-hg implementations). I have not yet tried it myself, but you can find it at https://github.com/glandium/git-cinnabar

更新 3：目前没有积极维护 gitifyhg 和 Felipe 的 git-remote-hg。目前，我制作了一种形式的 Felipe 代码，并进行了一些修复，包括一些使其适用于最近的 Mercurial 版本。您可以从https://github.com/fingolfin/git-remote-hg获取它。最后，还有另一个最近的竞争者，git-cinnabar在内部使用完全不同的方法（尽管如果您不关心这一点，使用它或多或少与其他 git-remote-hg 实现相同）。我自己还没有尝试过，但你可以在https://github.com/glandium/git-cinnabar找到它

回答by Thomas Broyer

hg-git apparently can be used to work with git locally, with a remote mercurial repo: http://traviscline.com/blog/2010/04/27/using-hg-git-to-work-in-git-and-push-to-hg/

hg-git 显然可用于在本地使用 git，使用远程 mercurial 存储库：http: //traviscline.com/blog/2010/04/27/using-hg-git-to-work-in-git-and -推到汞/

Don't miss the comments there too.

也不要错过那里的评论。

回答by FelipeC

Somebody already mentioned two git-remote-hg's, but here's a new one:

有人已经提到了两个 git-remote-hg，但这是一个新的：

Bridge support in git for mercurial and bazaar

在 git 中为 mercurial 和 bazaar 提供桥接支持

It has more features and should work more reliably than the msysgit one, but most importantly; you don't need any dependencies or a custom git build. Just copy to your $PATH, and that's it.

它具有更多功能，并且应该比 msysgit 更可靠，但最重要的是；您不需要任何依赖项或自定义 git 构建。只需复制到您的$PATH，就可以了。

It has extensive tests to check that the output is exactly the same as hg-git, so it should work at least as well.

它有大量的测试来检查输出是否与 hg-git 完全相同，因此它至少应该也能正常工作。

回答by abourget

There is a new project that accomplishes just that:

有一个新项目可以做到这一点：

• https://github.com/abourget/git-hg-again

• https://github.com/abourget/git-hg-again

It does the two-way thing nicely integrated.

它很好地集成了两种方式。

回答by Cascabel

I think there really just isn't much incentive to create one. No one's going to be horribly crippled by having to use one over the other; they're both DVCS. Sure, everyone probably has their preference, but they'll generally just suck it up and use the other if they have to. I assume hg-git has come about because git is very widely used, while far fewer projects have adopted hg.

我认为真的没有太多的动力去创造一个。没有人会因为不得不使用一个而不是另一个而严重瘫痪；他们都是 DVCS。当然，每个人都可能有自己的偏好，但他们通常只会在必要时吸收并使用另一个。我认为 hg-git 的出现是因为 git 使用非常广泛，而采用 hg 的项目要少得多。

In constrast, if a project is using svn or cvs, anyone who's had a taste of DVCS is going to be hurting - and they'll want that git-svn/hg-svn utility. There are a lot of projects out there using cvs/svn still, so plenty of demand.

相反，如果一个项目使用 svn 或 cvs，任何尝过 DVCS 的人都会受到伤害——他们会想要 git-svn/hg-svn 实用程序。仍然有很多项目在使用 cvs/svn，所以需求量很大。

You're probably right that it'd be a useful thing to have, though, assuming one of the two doesn't slowly win out over the other (git really does have a much larger userbase, I believe).

不过，假设两者中的一个不会慢慢战胜另一个（我相信 git 确实拥有更大的用户群），你可能是对的，这将是一件有用的事情。

You're also right that there are no big technical obstacles - hg-git is bidirectional, so clearly it's possible to map the information between the two.

没有大的技术障碍也是对的 - hg-git 是双向的，所以很明显可以在两者之间映射信息。