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

From: David Kastrup <dak@gnu.org>
Date: Aug 22, 2007, 14:29 UTC
Message-ID: <864pirej6w.fsf@lola.quinscape.zz>
In-Reply-To: <46CC3C17.8040901@op5.se>

Andreas Ericsson <ae@op5.se> writes:

Show 27 quoted lines

> David Kastrup wrote:
>> Carlos Rica <jasampler@gmail.com> writes:
>>
>>> This is the first version of the program "builtin-reset.c",
>>> intended for replacing the script "git-reset.sh".
>>>
>>> The --mixed option with -- paths is not implemented yet.
>>>
>>> The tests I made for it are not finished so they are not included,
>>> but it seems to pass the rest of the test suite.
>>
>> Could you be so kind as to give a one-sentence summary what the
>> benefits over using a shell script would be?
>
> One word: Portability.
>
> There's a plethora of various shell syntaxes. Discerning what's
> correct shell and what's a bash'ism that may or may not be posixly
> correct (but perhaps not supported on a multitude of out-of-the-box
> solaris system) has so far taken almost as much time as convincing
> newcomers to git that there really is no point in tracking file
> renames explicitly.
>
> Otoh, the list of large and renowned projects that have shunned git
> for its weak windows support grows longer, meaning we potentially
> lose competent programmers simply because they're forced to use
> something else.

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.

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.

When the Unix toolchain is not the main focus, a very interesting language for such projects is Lua <URL:http://www.lua.org>. It is (among hundreds of other applications) used as a scripting, programming and extension engine for LuaTeX (now in beta), the designated PDFTeX successor. It is very portable, efficient and minimalistic, while being quite expressive at the same time.

Show 11 quoted lines

>>  So unless there is some issue that can't be addressed reliably or
>> efficiently by reverting to other commands for everything involving
>> bulk processing, I am not really happy to see shell scripts
>> replaced.
>>
>
> It will happen, sooner or later. We may not like MS or their
> products, but sooner or later we'll have to cater to their users or
> face the problem of all the competent programmers helping out on
> some other SCM, because that other SCM works everywhere, while git
> doesn't.

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.

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.

-- 
David Kastrup