Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Fri, 23 Nov 2007, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:
> > 
> > > > Maybe you want to specify if all blobs should be output first, and 
> > > > then the commits?  Or files should be used?  But all of these things 
> > > > seem to be useless to me.
> > > 
> > > No, I want the program to wait for me to tell it what 
> > > blobs/commits/trees I want. The commit I want to see secondly may depend 
> > > on the output I read in the first request blob. Right now, for each data 
> > > dependency I have to start a new git process.
> > 
> > It does not seem like you want a mirror of fast-import, but rather a 
> > driver.  You might be happy to hear that you can do that already.  Today.
> > However, you probably want to query different programs about certain 
> > states of the repository.  This will not change.
> > 
> > > > > Besides being a nuisance, I actually run git on NFS, and every git 
> > > > > process has to go to NFS a couple times to retrieve the same 
> > > > > information. This has a noticeable performance impact.
> 
> I have been considering creating a "git-gui daemon" process that links 
> to libgit.a and can be driven bidirectionally through its stdin/stdout.  
> Based on git-fast-export, sorta.  But I haven't even started it...
> 
> But the idea is sort of what Han-Wen wants.  Why should I fork rev-parse 
> to get a ref value?  Or update-ref to change one?

I was thinking about this a little bit more.  But I cannot think of a 
really versatile way of enhancing fast-export enough to be of use there.  
Well, if not doing something with SWIG, that is ;-)

Ciao,
Dscho