[PATCH 2 of 2] templatekw: introduce the changessincelatesttag keyword

Matt Harbison mharbison72 at gmail.com
Sun Jun 28 11:51:38 CDT 2015


On Sun, 28 Jun 2015 07:03:21 -0400, Yuya Nishihara <yuya at tcha.org> wrote:

> On Sat, 27 Jun 2015 12:50:48 -0400, Matt Harbison wrote:
>> On Sat, 27 Jun 2015 09:15:33 -0400, Yuya Nishihara <yuya at tcha.org>  
>> wrote:
>> > On Sat, 27 Jun 2015 00:01:24 -0400, Matt Harbison wrote:
>> >> +def showchangessincelatesttag(repo, ctx, templ, cache, **args):
>> >> +    """:changessincelatesttag: Integer. All ancestors not in the
>> >> latest tag."""
>> >> +    latesttag = getlatesttags(repo, ctx, cache)[2][0]
>> >> +    offset = 0
>> >> +
>> >> +    if ctx.rev() is None:
>> >> +        if ctx.dirty(missing=True):
>> >> +            offset = 1
>> >
>> > IMHO, offset is always 1 because the wdir revision exists no matter if
>> > it is
>> > dirty or not.
>>
>> Is there an ease of coding something factor?  It seems a bit surprising  
>> to
>> me if you clean update to a tag, that immediately the change count is 1.
>
> We expect that "hg log -r 'wdir()'" shows something related to the wdir  
> even
> if it is clean, which means that the clean wdir resides in the log.
>
>   T -- 1 -- 2 -- wdir()
>                  [clean]

Makes sense.

> In the example above, if 'only()' could handle 'wdir()', 'only(wdir(),  
> T)'
> should be evaluated to [1, 2, wdirrev]. So I think the offset should  
> always
> be 1 for consistency.

Ah, so there's the difference.  I don't think of this keyword as "_offset_  
 from latest tag", but "how many _changes_ since the latest tag", where  
changes are measured in commits + what could be committed.  (Obviously a  
clean wdir() can't be committed.)  There's already a distance keyword.   
(What I'm proposing here would change the current invariant of changes >=  
distance to changes >= distance - 1.)

>> I added something like this to a build script:
>>
>>      hg log -r "wdir()" -T
>> "{latesttag}+{changessincelatesttag}-{p1node|short}{if(files,'+')}\n"
>>
>> and cut on the first '+' if the value between '+' and '-' is zero.
>> Treating a change count of 1 as the tagged release is why it seems  
>> weird.
>
> Perhaps it would need something to select the revision to be displayed,
> for example:
>
>   hg log -r 'last(. + wdir() & file("**"))' -T '...{ifeq(node, "ff...",  
> "+")}'

Maybe it is something wrong with the intersection of last() and dirty  
wdir(), but:

$ ../hg log -r '. + wdir() & file("**")'
changeset:   27772:d8cc3dd1acc6
tag:         tip
user:        Matt Harbison <matt_harbison at yahoo.com>
date:        Sat Jun 27 13:00:11 2015 -0400
summary:     revset: Yuya's patch to support kwargs

changeset:   27772:d8cc3dd1acc6+
user:        Matt Harbison <matt_harbison at yahoo.com>
date:        Sun Jun 28 11:48:00 2015 -0400

$ ../hg log -r 'last(. + wdir() & file("**"))'
$

$ ../hg log -r 'first(. + wdir() & file("**"))'
changeset:   27772:d8cc3dd1acc6
tag:         tip
user:        Matt Harbison <matt_harbison at yahoo.com>
date:        Sat Jun 27 13:00:11 2015 -0400
summary:     revset: Yuya's patch to support kwargs

>> Certainly I could change that from 0 to 1 and put a comment in.  I'm  
>> more
>> worried about this keyword and {latesttagdistance} agreeing when given a
>> few linear commits on a tagged revision:
>>
>> 		T -- o -- o -- wdir()
>>
>> Currently they do not (except a clean wdir() on T), because
>> committablectx.tags() returns the parents' tags.  I commented that out,
>> and the 'identify' tests fail.  Maybe identify can be fixed up to  
>> manually
>> look at the parent's tags.  Since wdir() isn't documented, I don't think
>> that's a breaking change.  I didn't try because I found this at work  
>> when
>> dealing with something else, and didn't get back to it.
>>
>> If you always consider wdir() to be a distinct change or "commit", it
>> really can't have the same tags as it's parents without violating the  
>> 1:1
>> relationship between tag and cset.  (Not that a user is likely to notice
>> or care.)
>
> Actually "hg log -r 'wdir()' -T '{tags}'" is empty thanks to the  
> namespace
> API, though '{latesttag}' computation is wrong. Maybe wctx.tags() should  
> be
> empty as well.

I hadn't noticed that '{tags}' behavior, and summary puts the tags on a  
line that explicitly says 'parent'.  I can't think of anything else where  
tags + wdir come into play, so I'll see if I can fix wctx.tags(), and that  
should fix '{latesttag}'.

> If clean wdir were identical to its parent, -r 'wdir()' should be  
> evaluated
> to the working parent. It seems odd and won't work as expected:
>
>   hg log -r "wdir()" -T '...{p1node|short}'
>
> So I consider that the identify command has an abstraction to skip clean
> working directory.

I agree it would be a mistake to conflate the p1 and clean wdir() in  
general.  But this keyword is simply counting changes, and the sleight of  
hand is internal to it, like (it will be for) identify.  I understand the  
dynamic selection of '.' or dirty wdir() that you listed above, but it is  
pretty obscure and I never would have figured it out on my own.


More information about the Mercurial-devel mailing list