Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Wed, 22 Aug 2007, Nicolas Pitre wrote: > >> On Wed, 22 Aug 2007, David Kastrup wrote: >> >> > Personally, I would prefer an approach of using an embedded script >> > interpreter: then language incompatibilities become a non-issue. >> > git-busybox sounded like a great idea for portability. >> >> Indeed. And while the conversion of some script into C was the right >> thing to do performance wise, many other scripts are hardly performance >> critical. > > What is wrong with going from shell to C? That it is not a script language where cause and effect of tying simple functionality together is apparent, and easy to do. > C _is_ portable. Instead of relying on _yet_ another scripting > language, introducing _yet_ another language that people have to > learn to hack git, introducing _yet_ another place for bugs to hide, > why not just admit that shell is nice for _prototyping_? git-busybox would not be "yet another scripting language" that would need an introduction. Emacs did not become one of the most used editors by chance: it is exactly _because_ its scripting language Emacs Lisp is good for prototyping, and the prototypes can be _retained_ and improved. Once development is dead, the need for prototyping stops. >> > If the scripting engine of choice for cobbling together >> > prototypes remains the Unix toolchain outside of git proper, then >> > Windows users will _always_ remain second class citizens since >> > they will get to work with and on new porcelain much later than >> > the rest of the world: namely when somebody bothers porting his >> > new favorite tool for them to C. >> >> Right. > > And not making the scripts builtins helps Windows users how, > exactly? Red herring. The proposal was not to do nothing, but rather give git a dedicated scripting language internal to it. Two suggestions of mine with different advantages were git-busybox and Lua. A third one was once proposed by Linus with some code example: starting a scripting language from scratch. So obviously, the need for something like that is recognized, and not having to start from zero for that might be an advantage if a good, workable language can be found. You could better address my points if you did not keep me in your killfile. -- David Kastrup - To unsubscribe from this list: 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
