Thread (35 messages) flat view 35 messages, 17 authors, 2016-06-15

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

From: Nicolas Pitre <hidden>
Date: 2016-06-15 22:43:30

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help