Linus Torvalds <torvalds@xxxxxxxx> writes: > There are many portable interpreters out there, and I don't mean perl. And > writing a small "specialized for git" one isn't even that hard. In fact, > most of the shell (and bash) hackery we do now would be unnecessary if we > just made a small "git interpreter" that ran "git scripts". Before anybody mentions tcl ;-). I agree with the above in principle, but I am afraid that is only half of the solution to the problem Alex is having. In the longer term, libified git with script language bindings would make the way git things work together a lot better. I've always wanted to make merge-base a subroutine callable from other things, so that I can say "git diff A...B" to mean "diff up to B since B forked from A" ;-). That way, we would eliminate the current common pattern of piping rev-list output to diff-tree, or ls-files/diff-files output to update-index --stdin. These components live in the single process, a calling "git script", and will talk with each other internally. But we do need to talk to non-git things. git-grep needs a way for ls-files to drive xargs/grep, for example. diff --cc reads from GNU diff output. And for these external tools, the way they expect the input to be fed to them or their output is taken out is via UNIXy pipe. And the breakage Alex wants to work around is that the platform is not friendly to pipes, if you deny Cygwin. So I suspect avoiding shell would not help much. - : 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