Changing the wdir() {rev} and {node} output

[Yuya Nishihara]

On Mon, 29 Apr 2019 11:37:02 -0400, Jordi Gutiérrez Hermoso wrote:
> On Wed, 2019-04-17 at 08:29 +0900, Yuya Nishihara wrote:
> > On Tue, 16 Apr 2019 10:14:53 -0400, Jordi Gutiérrez Hermoso wrote:
> > > While I think it might be okay to keep the iternal values,
> > > 
> > > https://www.mercurial-scm.org/repo/hg/file/967c098eed33/mercurial/node.py#l39
> > > 
> > > I think it's far too confusing to expose them in the user interface.
> > > 
> > > A particular inconsistency I see is that we already have a way to show
> > > wdir(), for example. In a way, `hg id -T` is kind of an alias for `hg
> > > log -r 'wdir()' -T ... ` in a way that is not obvious. But trying to
> > > use '{node}' or '{rev}' in `hg id` results in exposing the internal
> > > revision and node magic numbers, which is very confusing behaviour,
> > > since the default behaviour of `hg id` is to show `{p1.rev}+` instead
> > > if there are changes in the wdir.
> > > 
> > > Another instance in which this happens is `hg annotate -r 'wdir()'`,
> > > which also shows plusses to indicate that the changes are only in the
> > > working directory.
> > > 
> > > I think we should keep this behaviour throughout, for consistency.
> > > Since `wdir()` is still marked as experimental, we can change its
> > > current behaviour. I propose consistency with `hg id` as follows:
> > 
> > First, I'm okay to change the output of "hg whatever -r 'wdir()'" if that
> > makes things more consistent. However, {rev}/{node} keywords should still
> > return wdirrev/wdirhex since they are valid identifiers whereas "<p1node>+"
> > isn't.
> 
> But this is the problem that we currently have. It's difficult to
> produce the default template of `hg id` unless you dig deeper into
> template syntax.

Isn't it just -T "{id}"?
(CC Matt Harbison as he is the expert of the id template.)

> Maybe we should just make the `+` part of the syntax
> for parsing revnums... but that conflicts with revset syntax, oh
> bother.
> 
> Could we add a unary postfix `+` operator to revsets?

No. It would make revset parsing more ambiguous, and the idea was rejected
a few years ago.

> > >     * If the working directory is clean, the following are equivalent:
> > > 
> > >           hg log -r 'wdir()' -T '{rev}:{node}'
> > >           hg log -r . -T '{rev}:{node}'
> > 
> > Do you mean `hg log -r 'wdir()'` should fall back to '.' if wdir is clean?
> > I believe it'll be way complicated.
> 
> Maybe yes? Conceptually, showing the log for the wdir doesn't seem to
> be that useful of an operation. The only reason I can see for doing
> that is to get the current time and the current user, but that would
> probably be better done with dedicated template keywords.

Querying changesets is one use case of "hg log". For instance,
"hg log -r 'null:wdir() and file("b")' -T '{rev}'" will list any
(possibly-pseudo) revisions touching the file "b", and the frontend script
can fetch each revision data subsequently by "hg <whatever> -r <rev>" so
long as '{rev}' is a valid identifier.

> > If clean "wdir()" == ".", "hg status --change 'wdir()'" would have to
> > show the changes in "." as well, which makes no sense.
> 
> Hm, okay, I see the complication here. So maybe let's not do this
> except for display purpose of the {rev} and {node} template keywords.

That seems worse. "hg log -pr 'wdir()'" would show p1 rev/node plus
wdir diff.

I think the identify command is special in that "id -r 'wdir()'" works as
if it fell back to "id -r .". That's fine for id, which is pretty simple
command, but the other commands can produce various data in various ways.
Making everything consistent wouldn't be easy if we'd take the id command
way of wdir handling.