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
[RFC/PATCH 0/3] git log --pretty=lua
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. Here are timing results for a few log commands (best-of-five, warm cache): $ git log --oneline >/dev/null real0m1.042s user0m0.660s sys 0m0.372s $ git log --tformat:"%h %s" >/dev/null real0m1.039s user0m0.624s sys 0m0.396s $ git log --pretty=lua:'return abbrev(hash()) .. " " .. subject()' real0m1.112s user0m0.716s sys 0m0.388s So you can see that we're a little bit slower than the existing format, but not too much. There may well be some optimizations we can do, too. This is the first time I've ever played with embedding Lua, so I would not be surprised if I got something wrong or suboptimal. The syntax, on the other hand...yuck. 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. The patches are: [1/3]: pretty: make some commit-parsing helpers more public [2/3]: add basic lua infrastructure [3/3]: add a "lua" pretty format And a "4/3" patch would probably add "--lua-filter" as a revision option for limiting commits. The patches are very rough and not meant to be applied. For me, this was a bit of an experiment. I'm not sure if I like it or not. It seems like a cool direction to go, but to be perfectly honest, I do not generally feel like git's existing filtering or output are inadequate (sure, it's slower to pipe --pretty=raw out to a separate perl filter and then do fancy formatting, but it's usually fast enough, and it's very flexible). So I don't have plans to work on it more any time soon, but I thought I'd share in case anybody is interested. And if somebody wants to pick up the topic and run with it, I'd be happy to help. -Peff -- 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
