Re: [RFC/PATCH 0/3] git log --pretty=lua
On Tue, Sep 25, 2012 at 7:23 AM, Jeff King wrote: > Why Lua? I don't especially like it as a language. But it's designed for > this purpose, which makes it very lightweight and relatively simple to > embed. Another option is tcl. String-based approach feels more natural for pretty.c and shell users. >=8.1 supports utf-8. We might be able to share some routines between the embedded tcl interpreter and gitk/git-gui. The drawback is we won't get the speed of luajit if we ever need to (I'm looking at filter-branch, but I assume eliminating fork() should already give decent speedup). -- Duy -- 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
Re: [RFC/PATCH 0/3] git log --pretty=lua
Matthieu Moy writes: > Jeff King writes: > >> We've talked off and on about extending the --pretty=format specifiers >> to something more flexible. There's also been talk recently of more >> flexible commit-filtering (e.g., grepping individual notes). > > Mercurial has a similar thing, which can be a source of inspiration: > > http://www.selenic.com/hg/help/revsets > > On the one hand, if find it a bit overkill to have a full language for > this, but on the other hand, it allows expressing easily and explicitely > boolean operators. > > I would find > > git log 'grep(foo) or grep(bar)' > > very intuitive and elegant,... You have to be careful with "grep", though. It would be unclear what "and" there would mean if you replaced your "or" with. Peff's earlier examples e.g. git log --lua-filter=' return author().name.match("Junio") && note("p4").match("1234567") ' git log --lua-filter='return subject().len > 100' are clearly good ones that illustrate the power of filtering. -- 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
Re: [RFC/PATCH 0/3] git log --pretty=lua
Jeff King writes: > We've talked off and on about extending the --pretty=format specifiers > to something more flexible. There's also been talk recently of more > flexible commit-filtering (e.g., grepping individual notes). Mercurial has a similar thing, which can be a source of inspiration: http://www.selenic.com/hg/help/revsets On the one hand, if find it a bit overkill to have a full language for this, but on the other hand, it allows expressing easily and explicitely boolean operators. I would find git log 'grep(foo) or grep(bar)' very intuitive and elegant, while I never know whether git log --grep=foo --grep=bar is a OR or a AND (there was a patch recently to clarify the doc). Note that Mercurial's version seem to really act on sets of commits, not just individual commits, as it allows things like hg log -r 'sort(date("May 2008"), user)' or the equivalent of git's negative revision argument : "x - y" Changesets in x but not in y. So it would be more a new "git log --filter='some expression'", not a --pretty=lua. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Re: [RFC/PATCH 0/3] git log --pretty=lua
- Original Message - > From: "Nguyen Thai Ngoc Duy" > Sent: Tuesday, September 25, 2012 7:22:49 AM > Subject: Re: [RFC/PATCH 0/3] git log --pretty=lua > > On Tue, Sep 25, 2012 at 7:23 AM, Jeff King wrote: > > We've talked off and on about extending the --pretty=format > > specifiers to something more flexible. There's also been talk > > recently of more flexible commit-filtering (e.g., grepping > > individual notes). Rather than invent a new Turing-complete > > language, I thought I'd try building on somebody else's work by > > embedding an existing language. > > > > Why Lua? I don't especially like it as a language. But it's designed > > for this purpose, which makes it very lightweight and relatively > > simple to embed. > > Personally I'd prefer a Scheme variant. Scheme only brings up bad memories for me ;) And while we use Lua at $dayjob, I, like Peff, am not a huge fan of the syntax. So turning to the internet to solve my problem, a quick Google search for embeddable scripting languages (assuming the heavyweights like Perl and Python are already out) produces Lua, JavaScript or specifically SpiderMonkey [1] (yay buzzword compliance!), Ch [2] (unfortunately closed source), and AngelScript [3]. >From a brief read of the webpage, AngelScript looks pretty interesting. I'm much better with (and thus preferential to) Python and Perl myself, but I can understand anyone's reservation in bundling/depending on libraries of that size. [1] https://developer.mozilla.org/en-US/docs/SpiderMonkey [2] http://www.softintegration.com/ [3] http://angelcode.com/angelscript/ Thanks, Stephen -- 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
Re: [RFC/PATCH 0/3] git log --pretty=lua
On Tue, Sep 25, 2012 at 7:23 AM, Jeff King wrote: > We've talked off and on about extending the --pretty=format specifiers > to something more flexible. There's also been talk recently of more > flexible commit-filtering (e.g., grepping individual notes). Rather > than invent a new Turing-complete language, I thought I'd try building > on somebody else's work by embedding an existing language. > > Why Lua? I don't especially like it as a language. But it's designed for > this purpose, which makes it very lightweight and relatively simple to > embed. Personally I'd prefer a Scheme variant. > The syntax, on the other hand...yuck. Oops. Scheme is out then. > One thing that makes Lua > horrible for this use is that it does not have interpolated strings. > However, there are template libraries for Lua, so maybe there's > something there. For --pretty, the first thing I looked up was utf-8 support and Lua does not seem to have that built in. Libraries can help but it'll be more verbose than native language support. > And a "4/3" patch would probably add "--lua-filter" as a revision option > for limiting commits. I was thinking of nearly the same thing, except that I hide the filters behind sha-1 extended syntax. Users can link @{foo} to a lua function, for example. I wonder what areas in git might benefit from such a scripting language, and whether someday we would convert some of git builtin commands to $NEWLANG, if $NEWLANG proves easier to maintain for complex logic commands. grep and rev-list (searching in general) are probably where $NEWLANG shines. But for really complex searches, one may want to go with libgit2 or other bindings to their favourite language than one git may provide. gitignore and gitattributes can make use of $NEWLANG but it has to be really fast. There was talk about conditionals in config file, which $NEWLANG might also help. In general I'm quite happy with what git provides. There are many advanced features that I have never used/or even aware of. -- Duy -- 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