And Linus Torvalds writes: - - 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). But for recommending and using git on these systems _now_... Simply translating the shell script into C with execs doesn't help if you're execing one of the known problems, or if the script has embedded, non-trivial Perl. git-clone is the major blocker; a trivial translation would be a great step but won't let people without GNU utilities clone repos. Plus, alas, Perl modules and Python version drift can be a bit of a problem on the same semi-pristine (or unmaintained, or too-stable) systems, so shell isn't the only thing that needs to go. And that'll take a good deal of effort. Note that my code snippets weren't a suggested patch. I wouldn't want the easy way out to impede progress on the right thing. But some local installations may find it much easier to patch git than to instruct users to change their utilities to match what git expects, especially if users have old scripts that would break if they changed their path globally. Luckily, git makes it really easy to keep those patches locally... Jason - : 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