[PATCH 2 of 2 PoC] hgweb: link to successors of obsoleted changesets (PoC)

[Anton Shestakov]

On Wed, 20 Dec 2017 22:01:49 +0900
Yuya Nishihara <yuya at tcha.org> wrote:

> On Fri, 15 Dec 2017 22:41:48 +0800, Anton Shestakov wrote:
> > # HG changeset patch
> > # User Anton Shestakov <av6 at dwimlabs.net>
> > # Date 1513346027 -28800
> > #      Fri Dec 15 21:53:47 2017 +0800
> > # Node ID 4273260ac0d6e9bcb293607c7bdc16d0d246e6e9
> > # Parent  3764b68ff62bb5144f814f17ffe6465bd915e51b
> > # EXP-Topic hgweb-more-info
> > hgweb: link to successors of obsoleted changesets (PoC)
> > 
> > This sort of works, but I have doubts about that "node" attribute that is
> > added. Something tells me that there may be a better way to do this, that's why
> > this is a proof of concept for now.
> > 
> > I'm not sure if there's a way to somehow access node and other changeset
> > attributes without actually adding them to this lambda function. But other
> > functions in templatekw module, like showparents, also use _hybrid() with a
> > similar makemap argument (a lambda that returns a dict with only ctx and
> > revcache), and if I do, for example
> > 
> >     hg log -T '{parents%"{node|short} {author} {date|isodate}"}'
> > 
> > it will show node, but also author and date, even though these attributes
> > aren't explicitly provided by anything in showparents().
> > 
> > But in hgweb, this is not enough, and there needs to be "node" in that dict,
> > otherwise the links wouldn't work. Any suggestions?
> 
> One way is to put repo and node to the commonentry.
> 
>   'ctx': ctx,
>   'repo': repo,
>   'node': templatekw.shownode,  # need to drop 'tmpl' from arguments
>   'succsandmarkers': templatekw.showsuccsandmarkers,
> 
> However, the story gets worse because hgweb overloads the keyword 'repo'
> for a repository name. This seems not easily fixable, so we'll have to bind
> a repo argument locally.
> 
>   'node': lambda ctx, **x: templatekw.shownode(repo, ctx),
>   ...
> 
> Ugly, but works.

Agreed, and for now I decided to try and do something that wouldn't
start bringing all regular template functions to hgweb (which, I feel,
would open a can of worms that this feature might not be worth).
There's a V2 of this series on the list.

I just saw your PoC patch that exports regular template functions to
hgweb after I sent my series, but I didn't look at it in detail yet. If
you think that's the way to go, then feel free to drop the second patch
from my V2. I guess the first patch can still be queued independently.