Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- Nov 23, 2007, 20:59 UTC
- Message-ID
- <20071123205958.GC14735@spearce.org>
- In-Reply-To
- <Pine.LNX.4.64.0711230149430.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 19 quoted lines
> 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.