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

["Shawn O. Pearce" <spearce@spearce.org>]

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?

-- 
Shawn.