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

[Theodore Tso <tytso@mit.edu>]

On Thu, Aug 23, 2007 at 11:31:56AM +0100, Johannes Schindelin wrote:
> 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.

Sure, but not all porcelein commands need the full power of C.  Take
"git-gc" for example.  It was a *very* short shell script before it
was rewritten to use C.

> 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 are you claiming that MingGW/MSys is so good that it has a
perl/bash that is fully Linux compatible, so that we don't need to
convert our various internal commands that are implemented in shell to
C?  I didn't think that was a commonly held assessment...

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

I don't know enough about LUA to say for sure.  Having taken a quick
look at lua.org, the implementation looks pleasantly small, and LUA
scripts look more comprehensible than say Tcl (which is not saying
much, I know).  But part of "show me the code" is people demonstrating
that no really, LUA is an appropriate tool for simple scripts that is
portable enough that we don't need to have external dependencies on
bash and perl, and that it is easier than rewriting all of our shell
scripts in C.  Maybe that is a true statement.  I don't know.  My
suggestion to "Show us the code" was a way of hoping someone who cared
enough about this issue could show us.

On Thu, Aug 23, 2007 at 11:55:41AM +0100, David Tweed wrote:
> 
> *nix person: "Dunno, I've never seen that before. I wonder what's
> causing it: is it a git thing I've never seen, is it a bash/Perl-on-Windows
> weirdness, is it something implemented not as expected in the cygwin
> libraries, is it native Windows behaviour that's actually "right"?
> Or is it some mixture of the four? And given that I've never
> used cygwin and other tools on windows, I'm ******** if I know...."

This is definitely the case with Cygwin, and I *thought* it was an
issue with MSys/MingGW.  Johannes seems to be arguing otherwise, but I
don't have first hand experience, since happily I haven't had to do
Windows development since 1999, when I stopped working on Kerberos at
MIT.  (Back then we had some really gross perl scripts that converted
Unix makefiles into Windows makefiles, and I used Cygwin, so I know
how unsatisfying that would be for a die-hard Windows programmer.)

> I personally don't care exactly what's used implementing git on non-unix
> platforms, but I get nervous as more and more "layers" are added so
> it becomes more and more difficult to figure which layer a user problem
> is occurring at. If it looks to difficult to "help out with" issues on Windows,
> that would be a big enough reason for me not to use git on such projects.

I think people are aware of that, and that's why the debate is going
on about either rewriting all internal shell scripts to C, or perhaps
using some extension language.

My personal belief is that for anything longer than a relatively
trivial size, the right answer *is* to rewrite it to C, and we have
some GSoC students doing just that.  But for some of the simpler
scripts, maybe it makes sense to consider LUA.  I don't know.  But
someone who cares is going to have to implement a proof of concept and
then convince everyone that it is worthwhile for the git community to
learn LUA.  If it's not a simple enough language, or write-only
language like Perl (quick!  what does this do?  
$_="krJhruaesrltre c a cnP,ohet";$_.=$1,print$2while s/(..)(.)//;),
then such a proposal will fall flat on its face.  But from my very
quick examination of LUA, it seems to avoid the obvious problems of
Perl (too easy to write obfuscated code, no stable language specification,
too big), Python (too big, no stable language specification), Tcl 
(awful syntax), so if someone is willing to champion it, it should be
given a fair hearing.

Or maybe we just convert everything over to C.  That's an acceptable
outcome as well, and probably the most likely given that we're doing
this already.

						- Ted