owner links? (was: author/committer/tagger links -- kernel.org?)

[Jason A. Donenfeld]

On Thu, Jan 16, 2014 at 2:46 PM, Kyle J. McKay <mackyle at gmail.com> wrote:
> And we use this hook:
>
>   $owner_link_hook =
>     sub { url_path($Girocco::Config::webadmurl).
>           "/projlist.cgi?name=".md5_hex($_[0]); };
>

Well, that wound up being totally trivial, and a logical thing to have
by default anyway:

http://git.zx2c4.com/cgit/commit/?id=a58e6863cfe4f1411fedd556a96d8f8b9bf75761
You can try it out on: http://git.zx2c4.com/



> Looking at top, gitweb is clearly a CPU pig on repo.or.cz (git clones can
> also be piggy but I expect that to drop significantly when the new pack
> bitmap support is deployed).  And besides, the cgit display just looks good.
> I'd like to add support for cgit to girocco [2] as an alternative to gitweb.
> When that's sufficiently mature I'd like to deploy it alongside gitweb on
> repo for a time and then we can talk about switching.  :)

That'd be very cool to see. What types of things do you see cgit
needing to facilitate this?

> As you can see from the hook text above the repo gitweb hook only offers the
> ability to attach a link, it doesn't actually let one generate the markup or
> change the displayed owner name.  That's all I really need.  On the project
> list page [3] there are thousands of these, so running a shell script for
> each one is a non-starter.  A simple regex is not good enough either because
> it needs to generate the md5 hash (probably ought to be md5_hex(lc($_[0]))
> too -- another TODO item).

I don't know how closely you read the list, but some exciting things
have been happening the last two weeks. I too didn't like the idea of
having to run a shell script everytime I wanted to add a gravatar to
an email address, but I didn't l like the idea of hard coding the
logic to do so into cgit itself. So I integrated Lua/LuaJIT. It's
super super fast, only needs to evaluate the script one time (and then
each email it filters reuses the same context), and most importantly,
doesn't need to fork ever. We're using this for the new authentication
framework too:

http://git.zx2c4.com/cgit/tree/cgitrc.5.txt#n578
http://git.zx2c4.com/cgit/tree/filters/email-gravatar.lua
http://git.zx2c4.com/cgit/tree/filters/simple-authentication.lua

So it seems most feasible to use this for email obfuscation. (As I
mentioned before, we already have the "noplainemail" config option,
but we should probably remove this in favor of using this new filter
API.)