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

Andreas Ericsson [off-list ref] writes:

David Kastrup wrote:

quoted

Carlos Rica [off-list ref] writes:

quoted

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.

quoted

 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