[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