[PATCH 1 of 2 V2] hgweb: move entry-preparing code from webcommands to webutils.commonentry()

Yuya Nishihara yuya at tcha.org
Mon Nov 23 05:16:28 CST 2015


On Mon, 23 Nov 2015 16:59:39 +0800, Anton Shestakov wrote:
> On Mon, 23 Nov 2015 12:39:07 +0900
> Yuya Nishihara <yuya at tcha.org> wrote:
> > On Mon, 23 Nov 2015 01:22:34 +0800, Anton Shestakov wrote:
> > > On Mon, 23 Nov 2015 01:52:54 +0900
> > > Yuya Nishihara <yuya at tcha.org> wrote:
> > > > On Sun, 22 Nov 2015 15:13:50 +0800, Anton Shestakov wrote:  
> > > > > # HG changeset patch
> > > > > # User Anton Shestakov <av6 at dwimlabs.net>
> > > > > # Date 1447396536 -28800
> > > > > #      Fri Nov 13 14:35:36 2015 +0800
> > > > > # Node ID b4c5ca5544c5b51cbe9f616d3821d07ff29f1073
> > > > > # Parent  df9b73d2d444ae82fe8d3fe6cf682a93b2c4a7ef
> > > > > hgweb: move entry-preparing code from webcommands to
> > > > > webutils.commonentry()
> > > > > 
> > > > > The new function is used to prefill basic information about a
> > > > > ctx, such as revision number and hash, author, commit message,
> > > > > etc. Before, every webcommand used to get this basic
> > > > > information on its own using some boilerplate code, and some
> > > > > things in some places just weren't available (e.g.
> > > > > branch/tag/bookmark info for the current hgweb revision in
> > > > > filelog).

> > > Yes, but only if there's no conflict, because otherwise it blows up
> > > with TypeError.
> > > 
> > > However, when it's required to override some of the keywords, this
> > > style wouldn't work. I'd rather make everything look similar, so I
> > > chose something that works in more cases.  
> > 
> > It seems we are moving to different directions. I want to eliminate
> > these overrides because they are pain to define a single (or a few)
> > static table(s) of the template keywords.
> 
> Now I see. How easy is it to implement a templatekw table for hgweb? I
> have no idea, so I'll probably try and send a V3 of patch #2 preceded
> with some minimal changes to get it working. And then we can think
> about this problem.

Perhaps it won't be hard to make a table of common keywords, but porting
everything would be difficult. Anyway, the V3 patches will help moving
things forward.

> > And some of them are wrong. For example, 'filecomparison' shows the
> > parent of the parent if the path is removed at that revision and if
> > it is modified at the parent revision.
> 
> Indeed filecomparison has some overrides that use fctx instead of ctx
> for calculating parents and children. Let's assume we can do what
> filediff or fileannotate do and use only ctx or only fctx (so far sounds
> plausible since the intent of these functions is similar). In that case
> we would no longer need to override 'parent' and 'child'. Then, we can
> remove 'branch' from webutil.changesetentry (and thus call
> nodebranchnodefault(ctx) twice, but whatever, it's not expensive) and
> we're almost done with removing all overrides.

Sounds promising.

filediff() and comparison() have special cases for a revision where a file
is removed. I guess it can be simplified by using the absentfilectx which
is recently introduced for filemerge.

> But then there are 'parent' and 'child' in webutil.changelistentry().
> They are needed for log in spartan style only, and they hide changeset
> parent and child where DAG is linear. They seem to be the only
> overrides that we can't drop. Any ideas?

Perhaps it can be reimplemented as a template filter? But I'm not sure,
let's revisit this later.


More information about the Mercurial-devel mailing list