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

Hi,

On Thu, 23 Aug 2007, Theodore Tso wrote:

On Thu, Aug 23, 2007 at 10:10:20AM +0100, Johannes Schindelin wrote:

quoted

quoted

quoted

Red herring.  The proposal was not to do nothing, but rather give git
a dedicated scripting language internal to it.

That is a really neat idea.

Why?  Why should just _having_ a dedicated scripting language _per se_ be 
a neat idea?  We do not _need_ it!  We script git in bash, perl, other 
people in Python, Ruby, and even Haskell.  So why should we _take away_ 
that freedom from others to script Git in whatever language they like 
most?  There is no good reason.

Users should be able to script in whatever language they want; that's
clear.  However, what some people were talking about was an internal
scripting language that would be used for writing git commands, as an
alternative to an alternative future where everything gets moved to C.

And that is _exactly_ where I fail to see benefits from.  You only get the 
full power of C by using C.  You only get the full power of all open 
source C programmers by using C.  And you only get the full flexibility, 
speed, name-your-own-pet-peeve using C.

Mind you, I use scripts a lot.  I even have some projects where I 
git-added a script to add aliases which are so large as to fit half a 
terminal.

But we should not _force_ people to have bash or perl when they do not 
plan to use it themselves.

(To accomodate those Windows users who for some silly reason refuse to 
install Cygwin, bash, and perl on their Windows development box.  :-)

I have seen boxes where the administrators locked down everything.  And 
Cygwin _does_ need to write the registry, and there is _no_ easy way to 
have two independent Cygwin installs on the same machine.  This is where 
MinGW/MSys really shines.

So for those people who think an internal scripting language would be a 
worthwhile way of implementing certain git commands, instead of 
converting them all to C, my suggestion would be to "show us the code".  
Actually create the git to LUA bindings, and then show how easily it 
would be to rewrite a bunch of the existing git commands which are 
currently implemented in shell in LUA instead.

And force everybody who wants to contribute to _those_ parts of Git to 
learn LUA?  It is not about languages.  It is about people.  Choosing an 
obscure language automatically limits your most valuable resource: people.

We saw that already with filter-branch (which saw some duplicate efforts, 
because one developer was not comfortable with shell; we had two different 
programs with different suboptimal behaviours).

But if people are just gushing over the glories of elisp and saying 
things like *someone* should create a scripting language for git, it's 
just going to be a waste of everyone's time.

Amen,
Dscho