Re: Git 1.3.2 on Solaris

[ Junio - see the "grep" issue ]

On Wed, 17 May 2006, Stefan Pfetzing wrote:

If the biggest issue is git depending on some GNU extensions, I'd really 
suggest
 (a) install all the normal GNU binaries, and put them in the path before 
     git just to get it working (and don't try to change git at all)
 (b) help send in patches that just remove the dependency entirely.

I've been - on and off - trying to libify most of the core git sources, so that the shell scripts can be re-written to be just plain C. Most of the time it's not actually even a huge amount of work, it's just somewhat boring.

Writing them as C usually gets rid of any dependencies on any GNU tools, and hopefully even cygwin. For example, we got rid of one "xargs -0" in the development branch pretty recently, thanks to making "git grep" a built-in.

Of course, I don't think anybody tried the new "git grep" on Solaris, and I think the solaris "grep" lacks the "-H" flag, for example. But that should be easy to fix (for example, replace the use of "--" and "-H" with putting a "/dev/null" as the first filename).

I don't think it's worth it trying to add some compatibility layer for the shell-scripts. We really do want to get rid of them, and the more people that help, the merrier.

In many ways, the libification effort isn't even needed. It's perfectly ok to turn a stupid shell-script (and they really all _are_ pretty stupid) into a builtin-cmd.c C file that just does something really easy like a "fork + execve()" translation of the original shell script.

The complete libification will take some time, and in the meantime, a few silly C files that hard-code the shell logic is probably much preferable to using the shell and all the problems that involves (like the whole problem with quoting arguments - just _gone_ when you do it as a execve() in a simple C program).

So anybody can help with this. If you know shell (and the git shell-scripts aren't even _advanced_ shell), and know some basic C, you're all set to do a trivial conversion from one to the other. And when the libification gets further, your conversion will probably help that (ie maybe libificaiton isn't complete, but a _part_ of the thing can be written to use the library interfaces instead of spawning an external program).

There aren't _that_ many shell programs, and a lot of them are really really trivial (ie they parse the arguments, and then do just a couple of external git commands).

			Linus