Andreas Ericsson <ae@xxxxxx> writes: > David Kastrup wrote: >> Carlos Rica <jasampler@xxxxxxxxx> 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. >> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
