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

From: Nicolas Pitre <nico@cam.org>
Date: Aug 22, 2007, 16:07 UTC
Message-ID: <alpine.LFD.0.999.0708221154150.16727@xanadu.home>
In-Reply-To: <864pirej6w.fsf@lola.quinscape.zz>

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.

Show 6 quoted lines

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

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

Nicolas