Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6

From: Linus Torvalds <torvalds@osdl.org>
Date: Feb 23, 2006, 19:51 UTC
Message-ID: <Pine.LNX.4.64.0602231143290.3771@g5.osdl.org>
In-Reply-To: <7virr5hnw4.fsf@assigned-by-dhcp.cox.net>

On Thu, 23 Feb 2006, Junio C Hamano wrote:

Show 8 quoted lines

>
> Linus Torvalds <torvalds@osdl.org> 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 ;-).

Well, I was thinking more of the "embeddable" ones - things that are so small that they can be compiled with the project. Things like Lua.

Now, Lua is not really very useful for this use case: our scripts are much more about combining other programs - piping the output from one to the other - than about any traditional scripting. Which, afaik, Lua isn't good at.

Show 8 quoted lines

> 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" ;-).

Yeah, we should libify some of it, to make things easier. That said, I don't belive in the "big-picture" libification. The fact is, a lot of git really _is_ about piping things from one part to another, and library interfaces work horribly badly for that. You really want more of a "stream" interface, and that's just not something I see happening.

I think one of the strengths of git is that you can use it in a very traditional UNIX manner, and do your own pipelines. And that will obviously NEVER work well under Windows, if only because it's not the natural way to do things.

Again, libification does nothing for that thing.

What I'd suggest using an embedded interpreter for is literally just the common helper scripts. We'll never make

	git-rev-list --header a..b -- tree | 
		grep -z '^author.*torvalds' |
		..

style interesting power-user pipelines work in windows, but we _can_ make the things like "git commit" work natively in windows without having to re-write it in C by just having an embedded interpreter.

And I very much mean _embedded_. Otherwise we'll just have all the same problems with perl and bash and versioning.

Show 5 quoted lines

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

I was really thinking more of a simple shell-like script interpreter. Something that we can make portable, by virtue of it _not_ being real shell. For example, the "find | xargs" stuff we do is really not that hard to do portably even on windows using standard C, it's just that you can't do it THAT WAY portably without assuming that it's a full cygwin thing.

		Linus