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

Yuya Nishihara yuya at tcha.org
Sun Jun 28 06:03:21 CDT 2015


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]

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.

> 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...", "+")}'

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

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.


More information about the Mercurial-devel mailing list