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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 23, 2007, 09:10 UTC
Message-ID: <Pine.LNX.4.64.0708231006220.20400@racer.site>
In-Reply-To: <3f4fd2640708221434i4f5650e0u9adb523742666f40@mail.gmail.com>

Hi,

On Wed, 22 Aug 2007, Reece Dunn wrote:

Show 22 quoted lines

> On 22/08/07, David Kastrup <dak@gnu.org> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > On Wed, 22 Aug 2007, Nicolas Pitre wrote:
> > >
> > >> On Wed, 22 Aug 2007, David Kastrup wrote:
> > >> > 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.
> > >
> > > And not making the scripts builtins helps Windows users how,
> > > exactly?
> >
> > 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.

Show 5 quoted lines

> > Two suggestions of mine with different advantages were git-busybox and 
> > Lua.  A third one was once proposed by Linus with some code example: 
> > starting a scripting language from scratch.
> 
> Do you have a link to the proposal?

Go search in the mailing list archives.  It's not hard to find.

Show 7 quoted lines

> > So obviously, the need for something like that is recognized, and not 
> > having to start from zero for that might be an advantage if a good, 
> > workable language can be found.
> 
> It would also aid the Windows porting effort by having a single, builtin 
> scripting engine that does not have differing behaviours on different 
> platforms.

What is your problem? msysGit is coming along pretty fine _without_ that maintenance nightmare of an own scripting language. We use bash and perl, thank you very much.

> One thing that will need sorting is the binding of the C 
> plumbing/builtin command API to the scripting language, but this 
> shouldn't be that difficult to do.

It is that easy that you could do it in an hour or so, right? Or not. We need a whole GSoC project to do that, since sorting out a decent API is _not_ easy.

Ciao, Dscho