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? -- Shawn. - 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
