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

Matt Harbison mharbison72 at gmail.com
Tue Apr 30 22:11:56 EDT 2019


On Tue, 30 Apr 2019 00:32:01 -0400, Yuya Nishihara <yuya at tcha.org> wrote:

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

Not quite, even ignoring tags, bookmarks and the branch.  For a simple  
dirty wdir:

$ hg id
05c9dcf5512e (stable) 8.5.1 @

$ hg id -Tjson
[
  {
   "bookmarks": ["@"],
   "branch": "stable",
   "dirty": "+",
   "id": "05c9dcf5512ed77490a35b4d6b1c3fe860259f48+",
   "node": "ffffffffffffffffffffffffffffffffffffffff",
   "parents": ["05c9dcf5512ed77490a35b4d6b1c3fe860259f48"],
   "tags": ["8.5.1"]
  }
]

For an uncommitted merge:

$ hg id
05c9dcf5512e+a790438049e8+ (stable) 8.5.1 @

$ hg id -Tjson
[
  {
   "bookmarks": ["@"],
   "branch": "stable",
   "dirty": "+",
   "id":  
"05c9dcf5512ed77490a35b4d6b1c3fe860259f48+a790438049e8b1cc2e73f432bf22acaf514b2b54+",
   "node": "ffffffffffffffffffffffffffffffffffffffff",
   "parents": ["05c9dcf5512ed77490a35b4d6b1c3fe860259f48",  
"a790438049e8b1cc2e73f432bf22acaf514b2b54"],
   "tags": ["8.5.1"]
  }
]

Note that {id|short} just shears off the string after 12 characters.   
Maybe it would help if we taught {short} to let the '+' (and the second  
node in the case of a merge) through?

I suppose we could also add {shortid} here.  But if part of the concern is  
not wanting to see ff..ff, maybe we can add {id} to the changeset  
templater for the log command too?  Use that for display, and {node} to  
feed to a program.  For commits, there would never be a '+' or second  
node.  That doesn't help with {rev} though.  Maybe a {display} filter  
would work for both {node} and {rev}?  (With a better name of course.)

There's some further discussion of the complications of wdir() in these  
threads:

https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-June/071588.html
https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-June/071631.html

(The magic needed to generate the version string in the first link seems  
unfortunate, but I don't have any solutions given the issues Yuya raised  
in this thread.)


More information about the Mercurial-devel mailing list