Git as mercurial client? Why no git-hg?

Question

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-svn and 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 Internals book, and the Mercurial Definitive Behind the Scenes to 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.

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.

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.

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.

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

Solution 1

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

Solution 2

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

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.

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

Solution 3

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.

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.

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

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-hg It works without requiring patches to git itself, though some patches to git (under review now) can be applied to improve the overall user experience.

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.

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

Solution 4

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/

Don't miss the comments there too.

Solution 5

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

Bridge support in git for mercurial and 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.

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

View more solutions

Comments

[Kai Inkinen]

From my experience git is gaining a lot of attention on the field, but so far a lot of companies I've been consulting, are selecting mercurial over git. The reason is most often, that mercurial is easier to grasp for someone with svn/cvs background, which is about 99% of all developers. This means that a lot of commercial VCS are being converted to mercurial, which effectively rules out git. For anyone using git, keeping the server as SVN would be better, due to git-svn. Developing this could really be a good PR stunt for git and thus interesting for git developers, don't you agree?

[Cascabel]

@aapeli: Interesting. I haven't surveyed, but my workplace uses git, and among free software projects, git seems to be much more popular. It's very unfortunate (but not surprising) that companies are using ease of transition from cvs/svn as a main reason - in an ideal world, they'd just pick the one that's better for their needs, and expect developers to learn to use it. And it's true, anything to get git more widely adopted would be good for the project - but the overwhelming support in the free software world will probably always be sufficient success to ensure git's future.

[jk.]

anyone got a transcript of this?

[jk.]

I would guess a lot of windows shops might pick hg over git due to perceived problems with git's windows support

[Tom Willis]

i don't know of one myself, but I found it pretty easy to follow

[Kai Inkinen]

At least a year ago when doing this kind of evaluation for a company doing java, we found that there were still a lot of things that were inferior in git, compared to mercurial. Some of the most important ones were no or bad IDE and CI environment support. The main tools where netbeans, eclipse and hudson. These do have a direct effect on the productivity. Windows was not an issue in this case, nor for a number of other similar cases I've heard of. AT least now the situation has improved, I guess.

[Cascabel]

@aapeli: I guess that makes sense. I know I have a really idealistic attitude about all these things. I don't really regard IDE interfaces as important - if you take the time to learn the commands, the command line interface does just fine, and you'll end up with better knowledge of how git actually works. As for CI... my attitude is that you should pick the VCS with the capabilities you want, then write a plugin for your CI tool if you have to. It's not like you need any really sophisticated VCS operations to clone checkout build clean etc.

[Kai Inkinen]

Well I agree with most parts, maybe not the IDE stuff, but I personally also like using the command line for most VCS stuff. However, sitting in a room full of people, of which one half think SVN is god sent tool for just about everything, these kind of issues do actually matter a lot. But I guess we are agreeing on just about everything. I'm not saying that either one of these (great) tools is about to become extinct, but as commonly known "SVN is our common enemy" and having the DVCSs work together would really aid the greater cause.

[Kai Inkinen]

Great presentation! Informative, and fun to watch. I actually hadn't seen this before, as I tend to avoid watching any videos online. Unfortunately I'm still not satisfied with the answer. If the functionality is already there, then why not take it all the way? I'll have to give hggit a try, but maybe I should throw an email at the bitbucket guys...

[Cascabel]

@aapeli: Yeah, I definitely agree with you on essentially everything. It's just a lot harder to convince corporations or developers with a long SVN history about it. I'd love to see git-hg as well, despite not using hg at all - anything to help bring down the monster of SVN, and to make the DVCS world even more friendly.

[Cascabel]

@aapeli: I'm not sure you'll get an answer you're happy with - ultimately, the right answer is probably: "There should be one, but for practical reasons there isn't yet. Maybe sometime soon if enough people get interested in."

[Tom Willis]

@aapeli: "take it all the way"? not sure what you mean, it's a 2 way bridge what more would you want? written for the express purpose according to the author to bring more people to the github party. I can't imagine what else would be needed but maybe I'm just happily naive to the whole situation. Unless you are talking about merging hg with git, I thought the presenter gave a pretty good explanation of why that won't happen so a 2 way bridge is as good as it gets I think.

[Kai Inkinen]

Well, I haven't been able to try hg-git yet, but if I understood correctly it's still more than one step process to push from git to hg. Also the phrase about some people using the bare git directory didn't sound all that reassuring. Git-svn just works. Even to an extent that SVN as a git backend seems like good option. At least from the presentation I figured that git-hg is still a few steps away from this. Note, I'm not suggesting that it's not a great project. I just feel there is still some work left.

[Tom Willis]

@aapeli OK I see what you mean now. I'm sure the polish will come with time, but that's just one guy who works for github maintaining that in his spare time. I'm glad it's there but I agree that "it just works" would be a win for everyone.

[Jed]

Scott makes a brief comment at 23:35 in that Pycon talk about working in git and pushing to mercurial.

[Albert]

It seems that someone else already added that. Check out this fork.

[Cosmin Stejerean]

I am the original author of git-hg. It's really just a set of shell wrappers around fast-export that I've used for tracking a remote hg repo. As indicated by Albert someone did add push support and I just merged that fork today. For some reason I must have been missing email notifications from GitHub because I had two pull requests opened a few weeks ago that I never noticed until today.

[Kai Inkinen]

Cool. will have to check it out. Although it's lately started to feel more and more projects are converting to git and mercurial is getting less interesting. Maybe it's just my perspective, but still...

[Mu Mind]

Easy to follow or not, surely it doesn't take an hour long speech to answer the question. A tl;dr would be nice.

[Tom Willis]

@MuMind be my guest and add one. :)

[dubiousjim]

Thanks for this tool. I posted a detailed discussion of it here (see especially the "Evaluation" page).

[dubiousjim]

As I explain in detail here, the method Git-Hg uses for pushing to Mercurial doesn't seem usable in practice. I've told Cosmin about this already; am just posting this comment here to help others who end up finding their way to these tools via the same searchpaths I did.

[Mikko Rantalainen]

How does git-remote-hg handle the impedance mismatch between hg branches and git branches (see my answer at stackoverflow.com/a/11223644/334451 for details)?

[Mikko Rantalainen]

About IDEs: if you're using Eclipse, I'd bet that git is winning choice in the long run because Eclipse project has already switched to git. They are eating their own dogfood with git support.

[Epu]

At pycon 2013, gitifyhg author sounded pretty confident. It says it's untested on windows, so I'm trying that out now.

[Paul Price]

gitifyhg is actually a fork of git-remote-hg, and I don't believe either requires hg-git (they use Mercurial python modules directly). The crew working on gitifyhg seems to be more responsive to bug reports than the guy that originally developed git-remote-hg, so I've moved on to gitifyhg.

[FelipeC]

git-remote-hg imports both named branches and bookmarks from Mercurial, since bookmarks are the same as Git branches, a 'foo' bookmark gets a 'foo' branch in Git. A 'bar' named branch however, gets a 'branches/bar' branch in Git. If you push anything while on top of that branch, all those commits get the label 'bar', so they end up in the named branch 'bar'. In addition, there's an hg-git compatibility mode, in which we do exactly the same as hg-git and add extra code at the end of a commit that specifies the Mercurial named branch. So no information is lost at all.

[Nilzor]

tl;dr: You don't need git-hg because hg-git on the "server" enables the client to push and pull from a hg repo without any extensions! See Thomas Broyer's answer below for instructions.

[Nilzor]

@dubiousjim : The link you provided doesn't explain anything in detail. Outdated link?

[dubiousjim]

I think it was this

[CharlesB]

felipec's solution is now integrated in Git, and works fine, so it should be preferred

[CharlesB]

felipec's solution is now integrated in Git, and works fine, so it should be preferred

[Jasper]

Link is dead. (and because this is a link-only answer, it renders the entire answer useless)

[Tom Willis]

thanks for letting me know. I updated the link after doing some searching.