On Wed, 22 Aug 2007, David Kastrup wrote: > 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. I tend to agree with you. > 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. Indeed. And while the conversion of some script into C was the right thing to do performance wise, many other scripts are hardly performance critical. There was a first attempt at a very specialized scripting language, even with a prototype a while ago from Linus: http://marc.info/?l=git&m=114076345427378&w=2 but the idea never took off. > 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. The current scripting ability will never go away. But it is less and less used meaning that scripting could never be a dependable ability on all platforms if the current trend continues. > 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. Nicolas - 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
