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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
