On Sun, 25 Jun 2017 01:23:41 -0400, Matt Harbison wrote:
> # HG changeset patch
> # User Matt Harbison <matt_harbi...@yahoo.com>
> # Date 1498360161 14400
> # Sat Jun 24 23:09:21 2017 -0400
> # Node ID 1e917448c8d5c36f19c41bc83793df3e92477ede
> # Parent 8299eb9b08c79699f496717d626842b72fa5ca4f
> identify: add template support
Great. Queued this, thanks.
> I left 'id' as a string because it seems very useful for generating version
> info. It's also a bit strange because the value and meaning changes depending
> on whether or not --debug is passed (short vs full hash), whether the revision
> is a merge or not (one hash or two, separated by a '+'), the working directory
> or not (node vs p1node), and local or not (remote defaults to tip, and never
> has
> '+'). The equivalent string built with {rev} seems much less useful, and I
> couldn't think of a reasonable name, so I left it out.
I think your choice makes some sense. identify acts quite differently from the
other commands. It wouldn't be possible to make it perfectly compatible with
log-like templates.
> Yuya mentioned using fm.nested() in that thread, so I did for the parent
> nodes.
> I'm not sure if the plan is to fill in all of the context attributes in these
> items, or if these nested items should simply be made {p1node} and {p1rev}.
[...]
> + for i, p in enumerate(parents):
> + fn = fm.nested('p%d' % (i + 1))
> + fn.startitem()
> + fn.data(rev=p.rev())
> + fn.data(node=p.hex())
> + fn.end()
I meant this could be a {parents} list, which is
fn = fm.nested('parents')
for ...
fn.startitem()
...
Each item could have fn.context(ctx=p) so that all template keywrods are
available.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
