> Three exported branch names "net.prjek:tester",
> "net.prjet:tester/drop-for-propagate" and "prjek.net:tester" where changed
> (with sed) during the import process because git does not allow colon's (and
> various other characters) in branch/ref names. I simply changed ":" and "/"
> in these names to "." although the "/" should have worked it did cause an
> error of some sort.
Maybe respect those limitations within mtn git_export?
Maybe... I'm not sure what we're replace all the bad characters with though. Apparently multiple consecutive dots (i.e. "..") are also disallowed so leaving this up to an intermediate script doesn't seem such a bad idea either.
In my experience with cvs_import, it's rather often the history, than
the end result, which looks strange. However, that's certainly harder to
check and git seems a tiny bit closer to the spirit of mtn, than CVS.
Agreed.
Hm.. maybe I just don't understand git fast-import format, but isn't the
ordering derived from the revision graph?
The ordering of the revisions is, but the ordering of the commands (add, delete, rename) within a single revision is not and monotone allows chains of renames that, for git, would have to happen in lifo order.
i.e. if a rev has the following: rename a b, rename b c, rename c d
it would have to be fed to git as: rename c d, rename b c, rename a b
... I think. I haven't actually tested this yet though so I could be wrong.
You are definitely underestimating the mtn world domination plan (tm).
Heh... I'm all for it, but we the bar has been raised considerably since monotone started and we'll have a lot of work to do!
Some questions aside: is there a "git fast-export"? Can you comment on
writing "mtn git_import"? Problems we are facing there?
There is a git fast-export. Writing a mtn git_import should be reasonably straight forward I think. I'm sure there will be some quirks though.
Cheers,
Derek