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

Matt Mackall mpm at selenic.com
Mon Jun 29 17:49:50 CDT 2015


On Fri, 2015-06-26 at 21:08 +0900, Yuya Nishihara wrote:
> 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.

Almost certainly not. At some point down the road, I expect we'll pass a
relevant context to the formatter, which will allow a template to do
ctx.user rather than each formatter call manually exploding all the
possibly interesting variables.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list