Re: [PATCH] Make "git reset" a builtin. (incomplete)

[Nicolas Pitre <nico@cam.org>]

On Wed, 22 Aug 2007, David Kastrup wrote:

> The problem I see is that C sucks really really bad as a scripting
> language, and tying together plumbing functionality into porcelain is
> one of the most powerful, flexible and hack-friendly features of git.
> Deprecating scripts is making git more opaque.

I tend to agree with you.

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

There was a first attempt at a very specialized scripting language, even 
with a prototype a while ago from Linus: 

	http://marc.info/?l=git&m=114076345427378&w=2

but the idea never took off.

> I am just not sure that C is the ultimate solution since it makes
> things harder to hack on.
> 
> I'd prefer to see some scripting abilities retained: many of the
> recent advances in the porcelain (like rebase -i) would likely not
> have happened if one would had to write them in C in the first place.

The current scripting ability will never go away.  But it is less and 
less used meaning that scripting could never be a dependable ability on 
all platforms if the current trend continues.

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


Nicolas