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)

Longer text (with lost pictures, sadly)

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.