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

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