On Tue, 30 Apr 2019 00:32:01 -0400, Yuya Nishihara <[email protected]> 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.)
_______________________________________________
Mercurial-devel mailing list
[email protected]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
