[RFC/PATCH 0/3] git log --pretty=lua

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
  real    0m1.042s
  user    0m0.660s
  sys     0m0.372s

  $ git log --tformat:"%h %s" >/dev/null
  real    0m1.039s
  user    0m0.624s
  sys     0m0.396s

  $ git log --pretty=lua:'return abbrev(hash()) .. " " .. subject()'
  real    0m1.112s
  user    0m0.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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]