From: Rocco Rutte <pdmef@gmx.net>
Date: Thu, 15 Mar 2007 22:07:05 GMT
Subject: Re: mercurial to git
Message-ID: <20070315220705.GD31087@peter.daprodeges.fqdn.th-h.de>
In-Reply-To: <20070315210406.GA8568@thunk.org>

Hi,

* Theodore Tso [07-03-15 17:04:07 -0400] wrote:
>Hopefully you won't mind that I'm adding the git list back to the cc
>line, since it would be useful for others to provide some feedback.

Not at all. Just wondering when others would get too bored... :)

>Actually, there *is* an hg-fast-import.  It exists in the hg sources
>in contrib/convert-repo, and it is being used in production to do
>incremental conversion from the Linux kernel git tree to an hg tree.
>So it does handle octopus merges already (it has to, the ACPI folks
>are very ocotpus merge happy :-).

I know convert-repo and like it as a starting point. But it has some 
problems like not properly creating hg branches, can import only one 
branch at a time which must also be checkout out on the git side, etc.

With 'hg-fast-import' I meant something like git-fast-import where 
clients can feed in more raw data instead of preparing each commit on 
its own and comitting it.

[...]

>So more practially, here are some of the things that we would need to
>do, looking at hg-fast-export:

>*) Change the index/marks file to map between hg SHA hash ID's instead
>of the small integer ordinals.  This is useful for enabling multisite
>conversion, but it is also useful for tracking tag changes in .hgtags.

The small numbers are the hg revision numbers which we'll need for 
git-fast-import. Ideally git-fast-import would allow us to use anything 
for a mark we want as long as it's unique. But I'm sure there's a cheap 
way of mapping revision to SHA1 in the hg API.

So, if anybody wants to join in writing up such a hybrid system, I'm for 
it. :)

   bye, Rocco
--