Re: [Monotone-devel] git fast-export

[Felipe Contreras]

On Wed, Jan 14, 2009 at 6:41 AM, Derek Scherger <address@hidden> wrote:
> On Tue, Jan 13, 2009 at 8:30 PM, Felipe Contreras
> <address@hidden> wrote:
>>
>> It seems to speed up at some points, I have tried again two times but
>> I had issues, I still don't have the numbers but it's probably faster
>> than what I thought.
>
> Yeah, it depends a lot on the length of the delta chains required to
> reconstruct rosters. Newer rosters reconstruct faster.
>>
>> > I have not verified this imported repo in any way yet though so who
>> > knows
>> > whether its accurate or not.
>>
>> I can verify comparing to the output of my tool, but there are some
>> differences:
>
> Good and bad I guess. ;)
>
>> 1) Your tool adds a bunch of "Monotone-" fields, can those be disabled?
>
> There's no option at the moment but it would be easy to add.

It would be really useful.

> Note that monotone revisions can have multiple authors, dates, changelogs,
> etc. if several people merge two revisions to the same result. The git
> fast-import format doesn't seem to allow more than committer and author and
> the monotone side doesn't indicate which would be which. So, at the moment I
> just grab one author, date and branch, cert and use that. I do concatenate
> all the changelogs and comment certs together for the git commit message and
> add the "Monotone-" values on to the end of that in case they are
> interesting.

I ignore the comments and use only the first value of changelog, date
and author. I set the committer to the first person that added a
changelog.

The git format only allows one author and one committer, but the
convention is to add multiple 'signed-off-by' lines for the people
that reviewed and accepted the patch. I have an option to add the
s-o-b lines, but I have it off.

I'm interested in a git repo that looks natural, not to have every
single bit of information from the mtn repo.

>> 2) There's no author mapping, can this option be added?
>
> I'm not exactly sure what you mean by author mapping but I assume
> translating between things like "address@hidden" and "Fred Flintstone
> <address@hidden>"? Is there a generally accepted format that other tools
> use for this?

Yes, that's what I meant.

The only format I know is the one from git-svn:
felipec = Felipe Contreras <address@hidden>

> This would be easy enough to add but with the caveat above about picking one
> author from several. We will very likely not agree on author or date on some
> revisions where multiple certs exist.

Right, but I don't think there's any point in trying to mirror exactly
the original repo; it's not possible. Lets just settle for a
reasonably good approximation.

>> 3) I add the mtn sha1 in refs/mtn/<id>
>
> This is easy to add too. I have added refs/mtn/roots/<id> and
> refs/mtn/leaves/<id> and was wondering about all of the monotone revision
> ids. I assume the leaf refs would prevent git from wanting to garbage
> collect otherwise unreferenced revs if there were any?

If there's a ref pointing to it, then it's not pruned.

>> Only 1) would be required to do a comparison, 2) would be great to
>> avoid converting the huge repo again without author mappings.
>
> Another option here is to process the exported output through
> sed/awk/perl/python during the fast-import phase. I suspect this may be
> needed in some cases anyway to fix branch names and things allthough I guess
> a branch mapping file would also be a possibility.

I don't like the sed approach.

Branches and tags can be manually fixed a posteriori, no big issue.
The important things are the commits themselves.

>> In order to do future updates I think 3) would be really great, that
>> way it's possible to know if a revision has been imported or not, and
>> makes possible to do quick lookups like: git show mtn/<sha1>.
>
> Yeah, this is probably worth having, at least for checking things over after
> an import. I'm not sure if you would want to keep these refs around long
> term or not. I was wondering about exporting the marks file as well, but
> this would probably be better.

It probably depends on the intent of the clone:
a) migrate the repo forever
b) mirror a mtn repo

Right now I'm interested in b), so I find the ref/mtn approach very
useful since I can quickly look for the mtn or git sha1.

> All of these things had crossed my mind previously and I'll probably get to
> them at some point.

Cool, then we are mostly in sync ;)

-- 
Felipe Contreras