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 07:59:27PM +0100, Jason A. Donenfeld wrote:
> On Thu, Jan 9, 2014 at 7:07 PM, John Keeping <john at keeping.me.uk> wrote:
> > 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.
> 
> Gravatar icons are placed next to author names (in the log for
> example) as well as the full email address (in the commit). So we'd
> have to give such a filter the email address, as well as the original
> string to be printed. Such memorization would then need to apply to
> that pair.

Presumably this would just pass the "A. U. Thor <author at example.com>"
string to the filter and we could just map that to the output.

> >
> > 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).
> 
> I do like this idea quite a bit. But the cost of forking indeed seems
> a bit high -- some listings have many many authors all at once. I'll
> investigate a little bit.

We could take an incremental approach like git-check-attr and friends do
when GIT_FLUSH=1, but I'm not sure how well we could delimit the output
in that case - I doubt a single line would be sufficient for all cases.
If we're not careful that approach could end up with capability flags
and other complex things like the fast-import protocol.

My gut feeling is that it /should/ be OK because CGit's caching layer
means that we don't actually regenerate pages too often and CGit tends
to be blazingly fast anyway, but it would be interesting to see some
benchmarks of how much overhead a call to "true" adds.