Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)

From: Theodore Tso <tytso@mit.edu>
Date: Oct 28, 2008, 21:31 UTC
Message-ID: <20081028213144.GC10862@mit.edu>
In-Reply-To: <20081028191234.GS24201@genesis.frugalware.org>

On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna wrote:

Show 8 quoted lines

> On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> > fast-import yet. If I understand dscho correctly, that exists now, so it 
> > should be easy enough to integrate that as well.
> 
> That's new to me. Theodore Ts'o once mentioned on this list that there
> is a "hg fast-export" but actually he just referred to "there is a
> git2hg conversion tool in hg's contrib dir" and it has nothing with
> fast-import.

The code I was referring to was called hg-fast-export, which is part of the "fast export" tools that front-end into git fast-import. The git repository can be found here:

	http://repo.or.cz/w/fast-export.git
	git://repo.or.cz/fast-export.git

I ended up using a very customized version of that script to convert the hg e2fsprogs repository to git.

In the past I've looked at the possibility of creating a bi-directional, incremental gateway between hg and git repositories. The main thing which makes this difficult is that hg stores tags in-band inside the change-controlled .hgtags file. This means that if you cut a release, tag it, and then create a commit to further modify the repository, the new commit is descended from the tag commit, whereas in git, the tag is a "bookmark" --- perhaps signed via GPG, but not part of the revision history.

I think the git method is much more sane, but what it means is that topologically, the commit tree for git and hg can never be identical. It also means that if you add a tag to a git tree after making several commits on that branch, how you reflect that in the hg repository is highly problematic. Do you rewrite the branch? Do you add the tag later on, disturbing the parent-child relationship of later commits? How do you keep track of when a tag hg repository topology if you are trying to maintain a bidirectional mapping between commits?

It's not impossible, but it makes it much more difficult, since in the hg world, tag commits can be inserted between arbitrary commits. This also means that if you want to create a bidrectional gateway between hg and git, it has to be a single gateway so it can keep track of this state information. If you try to have multiple gateways they would need to synchronize on when a tag entered the hg universe, and with what commit ID (and what timestamp).

						- Ted