Hi, On Tue, 27 Nov 2007, Karl Hasselstr?m wrote: > On 2007-11-26 16:48:14 +0000, Johannes Schindelin wrote: > > > On Sun, 25 Nov 2007, Karl Hasselstr?m wrote: > > > > > On 2007-11-23 15:59:58 -0500, Shawn O. Pearce wrote: > > > > > > > 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? > > > > > > Obviously, something like this would be very valuable for StGit as > > > well. > > > > Could you be a little more specific _what_ you want to do, and _how_ > > this could be done with fast-export | fast-import? > > Currently, a single StGit command can result in quite a few invocations > of git-cat-file, for example, each of which forks off a new process. If > it could start just one daemon such as Shawn proposed, and feed it > simple questions and commands about blobs, trees, commits, and refs, > that would probably be quite a lot faster. > > From what I understand, this is not something that would fit a > fast-export | fast-import pipeline. Which is why I didn't take the time > to elaborate on (or indeed find out) exactly which commands StGit would > like such a daemon to support. > > By the way: one command one _would_ likely want in the daemon is "list > modified files". Being long-lived (not when driven by StGit, perhaps, > but definitely when driven by git-gui or qgit), the daemon would be able > to use inotify for that. Ah, so you would like something like "git --interactive"? This is indeed a completely different scope than the fast-export thingie, which is meant as kind of a mysqldump tool. Indeed, you could use it even as a (kind of a) stash of the repo instead of the working tree. 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