Han-Wen Nienhuys <hanwen@xxxxxxxxx> wrote: > Wouldn't it make sense to build a git-fast-export, which > can be used to interrogate a git-repository: a GIT tool > could run a single git command, > > this would make interfacing with Git from scripts more ergonomical, > less dependent on changes in the UI of porcelains, and in some cases > more efficient. Maybe. But without knowing what the UI program wants, its hard to say what should be implemented there. I'm not going to create something on a hunch that it will be useful someday - that's just not a practical use of my time. Worse, most scripting level languages have a hard time working with a bidirectional pipe to a process. What you want here is stdin and stdout pipes, so you can send a command and then receive the response. This can be a challenge in something like Tcl, maybe not fully portable in Perl, etc. Even worse, some parts of Git are not reentrant. They are currently built to run once and have the UNIX process terminate quickly afterwards. Keeping it running to answer more queries from the UI may cause the Git process to leak memory over a longer term, cause it to crash after a couple of successive repack/prune/gc, etc. There are a number of interesting operations within Git that a UI would want to query, but that may not be a good idea to expose from a within a long running UNIX process, for those reasons. fast-import doesn't do these, so its reasonable to keep up for extended periods, but even fast-import assumes it will terminate at some point as it hangs onto its object table for the entire lifespan of the process. -- 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