Git as mercurial client? Why no git-hg?

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 hg-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?

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.

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.

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).

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.

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?

Kai Inkinen 2010-03-26 21:06:51

@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.

Jefromi 2010-03-26 21:12:10

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

jk 2010-03-26 23:33:15

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.

Kai Inkinen 2010-03-27 19:35:10

@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.

Jefromi 2010-03-27 19:45:13

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 2010-03-27 20:22:59

@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.

Jefromi 2010-03-27 21:11:30

anyone got a transcript of this?

jk 2010-03-26 23:01:53

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

Tom Willis 2010-03-27 17:02:05

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...

Kai Inkinen 2010-03-27 20:27:00

@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."

Jefromi 2010-03-28 02:18:50

@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.

Tom Willis 2010-03-28 13:44:13

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.

Kai Inkinen 2010-03-28 18:02:13

@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.

Tom Willis 2010-03-28 21:26:33

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

Jed 2010-10-12 10:55:35

ansaurus

tags:

views:

answers:

Git as mercurial client? Why no git-hg?

related questions