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

Mathias De Maré mathias.demare at gmail.com
Mon Aug 29 11:44:44 EDT 2016


On Tue, Aug 9, 2016 at 3:34 PM, Yuya Nishihara <yuya at tcha.org> wrote:

> 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".
>
Yes, I called it 'id' in this patch because of the '--id' flag. I agree,
'node'/'nodes' would be a better option.

>
> > 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, ...}].
>

Do you prefer I solve the above listed issues and resubmit? Or is this
patch in general not in the right direction?

Greetings,
Mathias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160829/e2917fcc/attachment.html>


More information about the Mercurial-devel mailing list