Re: [PATCH] Make "git reset" a builtin. (incomplete)
- From
David Kastrup <dak@gnu.org>
- Date
- Aug 22, 2007, 17:17 UTC
- Message-ID
- <86mywjcwv7.fsf@lola.quinscape.zz>
- In-Reply-To
- <Pine.LNX.4.64.0708221713540.20400@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 13 quoted lines
> 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.
Show 11 quoted lines
>> > 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