Questions about git-fast-import for cvs2svn

[Michael Haggerty <mhagger@alum.mit.edu>]

I've been reading the documentation for git-fast-import (thanks for the
fine documentation!) as part of determining how much work it would be to
add a git back end to cvs2svn, and I have a few questions.

1. Is it a problem to create blobs that are never referenced?  The
easiest point to create blobs is when the RCS files are originally
parsed, but later we discard some CVS revisions, meaning that the
corresponding blobs would never be needed.  Would this be a problem?

2. It appears that author/committer require an email address.  How
important is a valid email address here?

   a. CVS commits include a username but not an email address.  If an
email address is really required, then I suppose the person doing the
conversion would have to supply a lookup table mapping username -> email
address.

   b. CVS tag/branch creation events do not even include a username.
Any suggestions for what to use here?

3. I expect we should set 'committer' to the value determined from CVS
and leave 'author' unused.  But I suppose another possibility would be
to set the 'committer' to 'cvs2svn' and the 'author' to the original CVS
author.  Which one makes sense?

4. It appears that a commit can only have a single 'from', which I
suppose means that files can only be added to one branch from a single
source branch/revision in a single commit.  But CVS branches and tags
can include files from multiple source branches and/or revisions.  What
would be the most git-like way to handle this situation?  Should the
branch be created in one commit, then have files from other sources
added to it in other commits?  Or should (is this even possible?) all
files be added to the branch in a single commit, using multiple "merge"
sources?

5. Is there any significance at all to the order that commits are output
to git-fast-import?  Obviously, blobs have to be defined before they are
used, and '<committish>'s have to be defined before they are referenced.
 But is there any other significance to the order of commits?

All in all, I don't think that a git back end for cvs2svn would be very
trick at all.  There will be a bit of refactoring work to allow the user
to switch between SVN/git output at runtime, but so far I don't see any
reason that the fundamental algorithms of cvs2svn will have to be changed.

Thanks,
Michael