Here's a summary of changes I've made to the git exporter recently:
1. Added support for --import-marks and --export-marks options which work as described in the git fast-export manpage and should allow for incremental exporting.
2. Added checks to detect and correct name swaps (a->b + b->a), rename loops (a->b b->c c->a) and rename chains (a->b b->c c->d). Loops are broken by the introduction of a temporary name and chains are exported in reverse order (c->d b->c a->b) so that they can be handled properly by git.
3. Changed the processing of rosters to be done in reverse order, accumulating the changes between them before processing revisions in forward order and exporting them. The changes that are accumulated are similar to monotone revision objects but list deletions, renames and additions for files only. This makes processing the rosters quite a bit faster because it plays nice with the roster cache. It does require enough memory to hold all of the accumulated changes in memory while the process runs, which I think should be comparable to the amount of revision text data in the database being exported. For reference, my monotone database has about 18MB of revision text in 15000 revisions and an export process running on this database reaches about 203MB VSS and 126MB RSS. Exporting a pidgin database that I have laying around with 20MB of revision text in 27000 revisions reaches about 206MB VSS and 129MB RSS. These sizes aren't much larger than they were without the cached change information so that doesn't seem to have made a huge difference. The monotone export now takes about 22 minutes, down from 42 minutes and the pidgin export now takes about 1 hour, down from over 5 hours, so using some more memory seems to be well worth it. I haven't yet done a careful verification of these exports though so it's possible that they're completely hosed.