[PATCH 3 of 4] commands: add template support for identify

[Yuya Nishihara]

On Mon, 08 Aug 2016 21:08:39 -0400, Matt Harbison wrote:
> On Mon, 08 Aug 2016 11:54:45 -0400, Mathias De Maré  
> <mathias.demare at gmail.com> wrote:
> > # HG changeset patch
> > # User Mathias De Maré <mathias.demare at gmail.com>
> > # Date 1470200890 -7200
> > #      Wed Aug 03 07:08:10 2016 +0200
> > # Node ID 74056050d1bd9069f0dfaed861162ee65a77032d
> > # Parent  2a711c2a71c1e5e562fc988cfe9011ebf3d8e6e9
> > commands: add template support for identify
> >
> > Example output:
> > $ hg id -Tjson
> > [
> >  {
> >   "bookmarks": ["bar"],
> >   "branch": "stable",
> >   "changed": "",
> >   "id": ["5ebe437b3392"],

It's generally called as a "node" or "nodes".

> A subtle issue that I noticed: `hg id` with an uncommitted merge lists  
> both nodes:
> 
>    $ hg id
>    5af771ba5a5f+b8f9cdca8807+ tip
> 
> However, `hg id -T "{id}\n"` sticks them together without the '+' in  
> between:
> 
>    $ ../hg id -T "{id}\n"
>    5af771ba5a5fb8f9cdca8807
> 
> And it doesn't look like the % operator works, so you can't manually put  
> "changed" into the template, even though -Tjson seems to print "id" as a
> list:
> 
>    $ ../hg id -T "{ids % {id}}\n"
>    hg: parse error at 7: syntax error
>    $ ../hg id -Tjson
>    [
>     {
>      "changed": "+",
>      "id": ["5af771ba5a5f", "b8f9cdca8807"],
>      "tags": ["tip"]
>     }
>    ]

Good catch. We can't put a plain list into formatter. That's why I added
fm.formatlist().

> Also, not really a direct problem with this patch, though it opens the  
> door to it.  I saw the {tags} keyword, and tried using {latesttags()} from  
> the log templates.  This prints a stacktrace.  It's not clear to me to  
> what extent these templates are expected to work together.
> 
> It would probably be nice in the future to have keywords like  
> {latesttags}, {changessincelatesttag}, etc on `hg id` to be able to build  
> a string like `hg version`, but simpler than the magic currently required  
> when using `hg log` to do the same.  Also, I assume we can add {node} in
> the future, so that you don't need to use --debug to get the full hash?

Yeah, I'm thinking of an API to associate ctx with the current item. In order
to do that, each item should be mapped to a single revision, which means
we'll have to build [{"node": x}, ...] instead of [{"nodes": x, ...}].