On 8/22/07, David Kastrup <dak@xxxxxxx> wrote: > 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. Although I have never tested git-box (git-busybox) under Linux, I believe it would work well because all Unix specific code remains the same as in busybox. Making git-box part of git would increase git binary size by ~200kb IIRC. -- Duy - 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
