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.
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.
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?
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.
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?
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.
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.
All of these things had crossed my mind previously and I'll probably get to them at some point.
Cheers,
Derek