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

Matt Harbison mharbison72 at gmail.com
Wed Jun 24 20:08:49 CDT 2015

On Wed, 24 Jun 2015 10:16:06 -0400, Yuya Nishihara <yuya at tcha.org> wrote:

> On Tue, 23 Jun 2015 19:58:03 -0400, Matt Harbison wrote:
>> On Tue, 23 Jun 2015 19:00:47 -0400, Yuya Nishihara <yuya at tcha.org>  
>> wrote:
>> > On Tue, 23 Jun 2015 16:22:21 -0400, Matt Harbison wrote:
>> >> # HG changeset patch
>> >> # User Matt Harbison <matt_harbison at yahoo.com>
>> >> # Date 1435088760 14400
>> >> #      Tue Jun 23 15:46:00 2015 -0400
>> >> # Node ID 64ee46ed27022fc1033265f7d08dc48a9c71e91d
>> >> # Parent  7fdd1782fc4ee9da87d8af13e806dc9055db2c38
>> >> templatekw: add 'dirty' keyword to indicate a dirty working directory
>> >>
>> >> This displays a '+' if the context is a dirty working directory, the
>> >> same as how
>> >> the identify command prints a '+'.  It also works within an if  
>> clause,
>> >> +  $ hg log -r 'wdir()' -T "{if(dirty, '{p1node|short}',
>> >> '{node|short}')}{dirty}\n"
>> >> +  389aef86a55e+
>> >> +  $ hg log -r tip -T "{if(dirty, '{p1node|short}',
>> >> '{node|short}')}{dirty}\n"
>> >> +  389aef86a55e
>> >
>> > Do you plan to use the '{dirty}' keyword for log templates?
>> > I don't think it will be usable for the "changeset:" field because the
>> > wdir
>> > revision should be identified differently from the p1, even if it  
>> isn't
>> > dirty.
>> >
>> > % hg log -r 'wdir()' -Tdefault
>> > changeset:   29549:7fdd1782fc4e  # should have something even if it
>> > isn't dirty
>> > parent:      29549:7fdd1782fc4e
>> > user:        ...
>> I didn't plan on changing any canned template styles (I actually haven't
>> looked into how they work).  Would it be better to put the 'wdir()'
>> indicator on the tags line for the scenario you mention, so as to not
>> break the changeset line parsing?
>> My use case is I have build scripts that stuff a version into the things
>> that it builds- the plain tag value if there is one on '.', otherwise a
>> string like "3.4.1+685-6c48f012d37e".  But I can't tell from that if  
>> there
>> were any uncommitted changes, without a '+' if appropriate.
>> 'hg id' will give the "{node|short}+" part, but not the tag and  
>> distance,
>> so I am currently using log -T
>> "{latesttag}+{latesttagdistance}-{node|short}".  This would let me add  
>> the
>> optional '+'.
> Thanks, I got the reason why you need the {dirty} keyword.
> 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  

>   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.  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  

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.

>> 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?

More information about the Mercurial-devel mailing list