Re: Questions about git-fast-import for cvs2svn

Linus Torvalds [off-list ref] wrote:

On Sun, 15 Jul 2007, Michael Haggerty wrote:

quoted

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

Git itself doesn't really care, and many CVS conversions have just 
converted the username into "user <user>", but from a QoI standpoint it's 
much nicer if you at least were to allow the kind of conversion that 
allows user-name to be associated with an email.

Maybe git-fast-import could be taught to do the kind of user name 
conversion that we already do for CVS imports.. Shawn?

It could, but I'm not sure I want to implement it.  ;-)

I pretty much view source->Git translation as the business/policy
of the frontend, not of fast-import.  But we have three frontends
that all share the same file format (git-cvsimport, git-svnimport,
git-svn), and are all independent implementations.  Maybe pushing
it down into a tool like fast-import would benefit a lot of users,
and thus should be done.

I'll put it on my todo list.  Which is much longer than I have
time for.
 

quoted

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?

Not afaik. Git internally very fundamentally simply doesn't care (there 
simply _is_ no object ordering, there is just objects that point to other 
objects), and I don't think git-fast-import could possibly care either. 
You do need to be "topologically" sorted (since you cannot even point to 
commits without having their SHA1's), but that should be it.

Linus is completely correct here.  The only requirement on data
ordering is that all parent commits (from/merge lines) must
come before any child that depends on them.  But that's a pretty
reasonable request, as almost all VCS systems want data to come in
at least that order, if not something even more strict.

In theory marks could be used to stub in commits and let you feed
them out of order, but to make that work fast-import would need to
buffer them until it saw everything it needed to produce a SHA-1.
Not exactly a good idea.

-- 
Shawn.