[PATCH] templatekw: add 'dirty' keyword to indicate a dirty working directory

Yuya Nishihara yuya at tcha.org
Fri Jun 26 07:08:28 CDT 2015


On Wed, 24 Jun 2015 21:08:49 -0400, Matt Harbison wrote:
> On Wed, 24 Jun 2015 10:16:06 -0400, Yuya Nishihara <yuya at tcha.org> wrote:
> > My concern for {dirty} is that it isn't useful for ordinary revisions.  
> > Instead,
> > can we have a general form of {files} keyword?
> 
> Oh, I understand what you mean now.  I guess I'm not too concerned because  
> it basically disappears if applied to ordinary revisions, without the need  
> for conditional logic.
> 
> >   keyword   status subrepos
> >   --------- ------ --------
> >   file_adds A      no
> >   file_dels R      no       # gah, it should be _removes
> 
> I wondered about that, and why there's not one for the actual deleted  
> status.  But its the same issue as {dirty} I guess- not applicable  
> everywhere.
> 
> >   file_mods M      no
> >   files     MAR    no
> >   X(a, b)   a      b        # should it be a function or separate  
> > keywords?
> >
> >   e.g. append "+" if dirty file exists:
> >   {if(X("MAR!", "subrepos"), "+")}  # how to handle boolean "subrepos"  
> > flag?
> 
> That's interesting, and probably a good idea regardless of {dirty}, since  
> it could handle 'C' to show files that weren't touched by a revision.   
> {dirty} encompasses slightly more than file status, but that doesn't  
> matter for my use case.
> 
> I'm unsure about a secondary way of enabling subrepo support though.

Yep, I don't like it, but I have no better idea now.

> This
> seems reasonable for something like 'hg log', which will likely never grow  
> a -S arg.  But what about the files command, if it ever gets templatized?  
> It would be weird if -S didn't imply the subrepos boolean, and I don't see  
> a way for the templates to get access to the command line args to see if  
> -S was given.  It's probably equally problematic without -S and with  
> subrepos=True.

The files command does support the templates. See 0c6f98398f8a.
But because the new "X(status, ...)" function will require 'ctx', it won't be
usable there.

> There's also the similar issue for the revsets adds(), removes(), etc, and  
> how to get them to look into subrepos.  The syntax doesn't need to be  
> exactly the same, but a similar style might be nice if possible.

Agreed.

> >> I think we need something like this anyway to templatize the identify
> >> command.  (Probably less important now that log can be given "-r  
> >> wdir()".)
> >
> > Yes, but if "identify" command is ported to the formatter API, it will  
> > use
> > a different set of keywords.
> 
> I don't understand this comment.  Aren't all keywords from the same  
> general pool of keywords?  Wouldn't you need something for the '+' that it  
> currently prints?

We have two APIs that process -T template option:

 - cmdutil.changeset_templater can be used for log-like commands. It loads
   templatekw, so 'ctx' must exist in the mapping dict.
 - formatter.templateformatter is for the other commands. Keywords are passed
   by the caller.

I'm not sure if the identify command can use the changeset_templater.


More information about the Mercurial-devel mailing list