Jeff King <peff@xxxxxxxx> writes: > I think there are really two separate use cases to consider: > > 1. Providing snippets of script to Git to get Turing-complete behavior > for existing Git features. For example, selecting commits during a > traversal (e.g., a better "log --grep"), formatting output (e.g., a > better "log --format" or "for-each-ref --format"). > > 2. Writing whole new git commands in a language that is quicker or > easier to develop in than C. > > I think (1) is a good match for lua.... > > But for (2), you are going to care a lot more about the language and its > ecosystem (because you'll be interacting more with the world outside of > git), and about having bindings to lots of different parts of git > (because you'll want to do more interesting things than just examine a > few data structures). Good summary. We also need to realize that adding a native subcommand written in C has become much easier over time as our internal API has evolved and matured. These days, we still do a whole new command in scripts (and we have whole commands still in scripts) not because "quicker or easier to develop" (that is still true for throw-away experiments) but primarily because that is easier to modify and experiment over time until we find a solid design. Among the more important subcommands that are still scripts, I think "add -i", "repack", "pull", "stash" and possibly "rebase" have interfaces facing to both the end users and to the core part solidified enough that they can now be ported to C. Others either are not important enough or still have rooms to improve the interfaces in either direction that it would still be better to leave them in scripts (e.g. "bisect" with "<used-to-be, now-is> vs <good, bad>" issue unsettled, "submodule" with "floating" issue unsettled, etc.). -- 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