According to this blog post: Kiln now supports repositories accessible from both Git and Mercurial

We decided that the awesome way would be to make Kiln fully bilingual.
It stores every repo in both formats. It automatically converts
everything back and forth, always. The translation is 1:1, reversible,
and round-trippable. Whatever you do to a Kiln repository using Git
will be immediately visible to Mercurial users and vice versa.

I can't imagine that everything runs smoothly. What limitations does this have?

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

If a company wants to maintain any credibility with developers, don't knowingly release software that has limitations that will mess with their code and not tell them about it.
–
JeffOMar 17 '13 at 14:29

2 Answers
2

Well, I know at least one limitation of Git-HG conversion: Git stores less metadata in changeset for the same data, than Mercurial. And it can be easy detectable in handling of named branches (in Mercurial) and "just branches" of Git.

Conversion Git -> Mercurial -> Git lost nothing, repository before and after will be identical and equal

Conversion Mercurial -> Git -> Mercurial will have less data in final repository (branch-name is permanent attribute of any Mercurial changeset, Git branches are more Mercurial's "bookmark" - non-master changeset lost information about branch)

The limitation is if you need to convert between the two, you have to go through the central server that knows the mapping. You can't just push directly from your local git repo to your colleague's hg repo, like you can with pure git or pure hg.

Other than that, there aren't too many technical issues to overcome. Git and mercurial both have a commit as a fundamental unit and create a directed acyclic graph between the commits to represent branches. They both have universally unique identifiers for commits that include all the history leading up to them.

Now, two version control systems that aren't as similar would create more problems. The next level of difficulty would be a VCS like perforce, which has commits as a fundamental unit, but treats branches somewhat differently. A VCS like subversion, which has file revisions as a fundamental unit, would be very difficult indeed to keep a reversible mapping with.