Re: [RFC PATCH 3/3] Support fetching from foreign VCSes

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jan 12, 2009, 15:42 UTC
Message-ID: <20090112154224.GD10179@spearce.org>
In-Reply-To: <alpine.LNX.1.00.0901120041260.19665@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> wrote:

Show 8 quoted lines

> On Sun, 11 Jan 2009, Junio C Hamano wrote:
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> > > This supports a useful subset of the usual fetch logic, mostly in the
> > > config file.
> > 
> > I like the direction this series is going.  In the longer term, it would
> > be nice if we can have git-svn and git-cvsimport replaced with something
> > like this.

The series seems to require that the foreign tool speak fast-import. I've tried to get git-svn to use it, but its currently not possible because the git-svn process needs to be able to read objects it has written during this session. Those objects are stored in the output pack, where only the active fast-import process can get to them. Thus git-svn can't use fast-import.

As import as the git-p4 stuff is, git-svn is our "killer feature" when it
comes to foreign system integration.  I think we need to make SVN work for
this foreign vcs thing to work.

Show 6 quoted lines

> > Is the current foreign vcs interface sufficiently rich to support git as a
> > foreign scm by using fast-import and fast-export?
> 
> I think so, although it would be pretty strange, since it would generally 
> have a whole lot of local data (a complete clone of any remote 
> repository).

It might not be that bad. If the foreign system is git and the local system is git, we should have a massive amount of object reuse. At least all of the blobs from the foreign system should be reused by the local system, and that's like 80-90% of most project's object state.

If the import is flawless (no mangling of commit messages or history) then you should get 100% object reuse and the git-git import would give you the same SHA-1, but just slower than going over git://.

Its strange only because it would be sucking more CPU time on the client than is necessary to do the fetch. But if something like a filter-branch tool existed to massage a fast-import stream, it might be useful to fetch someone else's tree, massage it a bit, and then import it with a subtree merge. :-)

-- 
Shawn.