Re: git-fast-export ?

["Shawn O. Pearce" <spearce@spearce.org>]

Han-Wen Nienhuys <hanwen@xs4all.nl> 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.