Hi, On Fri, 23 Nov 2007, Shawn O. Pearce wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
