[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