>> 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.
I've added --log-revids and --log-certs to enable including revision ids and cert values in the commit logs. These are off by default .
>> 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?
The only format I know is the one from git-svn:
felipec = Felipe Contreras <address@hidden>
I've added --authors-file and --branches-file options that work like this for mapping author names and branch names respectively. Names not found in these maps are used as-is. I've also changed the default branch to "unknown" from "master" but this can be changed with the branches-file mapping to whatever you want with a line like "unknown = whatever-you-want."
>> 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?
I've added --refs=roots, --refs=leaves and --refs=revs to include refs/mtn/roots, refs/mtn/leaves and refs/mtn/revs respectively.
If there's a ref pointing to it, then it's not pruned.
Good. Including --refs=leaves should make sure that nothing is subject to garbage collection then.
Branches and tags can be manually fixed a posteriori, no big issue.
The important things are the commits themselves.
Not always. Monotone allows things in branch names that git does not. If these aren't changed git will fail to import them.
Use --branches-file to map offending names to something git can handle.
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.
The --refs=revs option does clutter up the gitk display somewhat but otherwise seems fine.
Cheers,
Derek