From: "Shawn O. Pearce" <spearce@spearce.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Haggerty <mhagger@alum.mit.edu>, git@vger.kernel.org
Subject: Re: Questions about git-fast-import for cvs2svn
Date: Mon, 16 Jul 2007 02:19:48 -0400 [thread overview]
Message-ID: <20070716061948.GG32566@spearce.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0707151119120.20061@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sun, 15 Jul 2007, Michael Haggerty wrote:
> > 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.
> > 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.
next prev parent reply other threads:[~2007-07-16 6:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-15 14:11 Questions about git-fast-import for cvs2svn Michael Haggerty
2007-07-15 16:01 ` Sean
2007-07-15 18:51 ` Steffen Prohaska
2007-07-15 18:58 ` Steffen Prohaska
2007-07-15 18:55 ` Junio C Hamano
2007-07-16 3:35 ` Eric Wong
2007-07-15 18:43 ` Linus Torvalds
2007-07-16 6:19 ` Shawn O. Pearce [this message]
2007-07-15 21:56 ` Robin Rosenberg
2007-07-15 23:21 ` Robin H. Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070716061948.GG32566@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.