RFE: author/committer/tagger links (enable cgit to show gravatar for author, committer and tagger)

[john at keeping.me.uk (John Keeping)]

On Thu, Jan 09, 2014 at 06:50:29PM +0100, Jason A. Donenfeld wrote:
> On Thu, Jan 9, 2014 at 4:21 PM, Konstantin Ryabitsev <mricon at kernel.org> wrote:
> > That's pretty nifty.
> 
> Cool. Would you consider enabling this on kernel.org? I'll probably
> merge it in a few days (still working out some bugs). Seems like the
> kind of thing that might give cgit a lot of positive attention...
> 
> > That reminds me -- I'm working on a web-of-trust
> > site for kernel.org and something I wouldn't mind having is a way to
> > link from cgit to the web of trust for that person. E.g. an email
> > address for "torvalds at linux-foundation.org" on this page
> > (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d6e0a2dd12f4067a5bcefb8bbd8ddbeff800afbc)
> > would be wrapped in a link such as:
> >
> > <a href="https://blah.kernel.org/?user=torvalds%40linux-foundation.org">
> > torvalds at linux-foundation.org</a>
> >
> > which will bring up a page similar to:
> > https://www.kernel.org/doc/wot/torvalds.html
> >
> > Not sure whether that would clash with any of your existing plans for
> > user links, but figured I'd bring this up for a discussion.
> 
> We already support module-link and repo.module-link for making
> clickable submodules. I don't see why we wouldn't be able to apply the
> same idiom to a email-link and repo.email-link setting. I'll look into
> this. I suppose a default setting, or maybe just a suggested setting
> in the documentation, would be to issue a search for that email. But
> this could then be used to instead link out to your upcoming web of
> trust platform. How does this sound?

It feels to me like it might be better to allow a filter to be applied
here.  That way we don't put the Gravatar code in CGit itself but can
distribute an example script that does apply Gravatar links to email
addresses.

I'm not sure what the cost of forking a process here will end up being
though; I guess for cases where the email is likely to be repeated we
could assume that the filter is pure and memoize the result.

But that would give the greatest flexibility for both these use cases,
with a simple link value the Gravatar case needs some other forwarding
program on the server to do the hashing of the address (unless we
provide substitution values for a range of different things, but
currently everything just uses printf formats so that would be more
work unless we can reuse Git's log formatter somehow).