Jeff King <p...@peff.net> 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
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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html