2019-12-10 02:24:31 +03:00
|
|
|
#chg-compatible
|
|
|
|
|
2014-08-06 20:43:59 +04:00
|
|
|
#require serve
|
2012-06-21 01:41:21 +04:00
|
|
|
|
|
|
|
#if no-outer-repo
|
2010-08-12 14:49:58 +04:00
|
|
|
|
|
|
|
no repo
|
|
|
|
|
|
|
|
$ hg id
|
2010-08-30 00:55:37 +04:00
|
|
|
abort: there is no Mercurial repository here (.hg not found)
|
2010-09-17 02:51:32 +04:00
|
|
|
[255]
|
2010-08-12 14:49:58 +04:00
|
|
|
|
2012-06-21 01:41:21 +04:00
|
|
|
#endif
|
|
|
|
|
2020-04-10 20:56:22 +03:00
|
|
|
$ configure dummyssh
|
|
|
|
|
2010-08-12 14:49:58 +04:00
|
|
|
create repo
|
|
|
|
|
|
|
|
$ hg init test
|
|
|
|
$ cd test
|
|
|
|
$ echo a > a
|
|
|
|
$ hg ci -Ama
|
|
|
|
adding a
|
|
|
|
|
|
|
|
basic id usage
|
|
|
|
|
|
|
|
$ hg id
|
2019-12-18 00:45:17 +03:00
|
|
|
cb9a9f314b8b
|
2010-08-12 14:49:58 +04:00
|
|
|
$ hg id --debug
|
2019-12-18 00:45:17 +03:00
|
|
|
cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b
|
2010-08-12 14:49:58 +04:00
|
|
|
$ hg id -q
|
|
|
|
cb9a9f314b8b
|
|
|
|
$ hg id -v
|
2019-12-18 00:45:17 +03:00
|
|
|
cb9a9f314b8b
|
2010-08-12 14:49:58 +04:00
|
|
|
|
|
|
|
with options
|
|
|
|
|
|
|
|
$ hg id -r.
|
2019-12-18 00:45:17 +03:00
|
|
|
cb9a9f314b8b
|
2010-08-12 14:49:58 +04:00
|
|
|
$ hg id -n
|
|
|
|
0
|
|
|
|
$ hg id -b
|
|
|
|
default
|
|
|
|
$ hg id -i
|
|
|
|
cb9a9f314b8b
|
|
|
|
$ hg id -n -t -b -i
|
2019-12-18 00:45:17 +03:00
|
|
|
cb9a9f314b8b 0 default
|
identify: add template support
This is based on a patch proposed last year by Mathias De Maré[1], with a few
changes.
- Tags and bookmarks are now formatted lists, for more flexible queries.
- The templater is populated whether or not [-nibtB] is specified. (Plain
output is unchanged.) This seems more consistent with other templated
commands.
- The 'id' property is a string, instead of a list.
- The parents of 'wdir()' have their own list of attributes.
I left 'id' as a string because it seems very useful for generating version
info. It's also a bit strange because the value and meaning changes depending
on whether or not --debug is passed (short vs full hash), whether the revision
is a merge or not (one hash or two, separated by a '+'), the working directory
or not (node vs p1node), and local or not (remote defaults to tip, and never has
'+'). The equivalent string built with {rev} seems much less useful, and I
couldn't think of a reasonable name, so I left it out.
The discussion seemed to be pointing towards having a list of nodes, with more
than one entry for a merge. It seems simpler to give the nodes a name, and use
{node} for the actual commit probed, especially now that there is a virtual node
for 'wdir()'.
Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes.
I'm not sure if the plan is to fill in all of the context attributes in these
items, or if these nested items should simply be made {p1node} and {p1rev}.
I used ':' as the tag separator for consistency with {tags} in the log
templater. Likewise, bookmarks are separated by a space for consistency with
the corresponding log template.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
|
|
|
$ hg id -Tjson
|
|
|
|
[
|
|
|
|
{
|
|
|
|
"bookmarks": [],
|
2017-06-26 00:46:35 +03:00
|
|
|
"dirty": "",
|
identify: add template support
This is based on a patch proposed last year by Mathias De Maré[1], with a few
changes.
- Tags and bookmarks are now formatted lists, for more flexible queries.
- The templater is populated whether or not [-nibtB] is specified. (Plain
output is unchanged.) This seems more consistent with other templated
commands.
- The 'id' property is a string, instead of a list.
- The parents of 'wdir()' have their own list of attributes.
I left 'id' as a string because it seems very useful for generating version
info. It's also a bit strange because the value and meaning changes depending
on whether or not --debug is passed (short vs full hash), whether the revision
is a merge or not (one hash or two, separated by a '+'), the working directory
or not (node vs p1node), and local or not (remote defaults to tip, and never has
'+'). The equivalent string built with {rev} seems much less useful, and I
couldn't think of a reasonable name, so I left it out.
The discussion seemed to be pointing towards having a list of nodes, with more
than one entry for a merge. It seems simpler to give the nodes a name, and use
{node} for the actual commit probed, especially now that there is a virtual node
for 'wdir()'.
Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes.
I'm not sure if the plan is to fill in all of the context attributes in these
items, or if these nested items should simply be made {p1node} and {p1rev}.
I used ':' as the tag separator for consistency with {tags} in the log
templater. Likewise, bookmarks are separated by a space for consistency with
the corresponding log template.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
|
|
|
"id": "cb9a9f314b8b",
|
|
|
|
"node": "ffffffffffffffffffffffffffffffffffffffff",
|
2020-01-07 23:29:27 +03:00
|
|
|
"parents": [{"node": "cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b", "rev": 0}]
|
identify: add template support
This is based on a patch proposed last year by Mathias De Maré[1], with a few
changes.
- Tags and bookmarks are now formatted lists, for more flexible queries.
- The templater is populated whether or not [-nibtB] is specified. (Plain
output is unchanged.) This seems more consistent with other templated
commands.
- The 'id' property is a string, instead of a list.
- The parents of 'wdir()' have their own list of attributes.
I left 'id' as a string because it seems very useful for generating version
info. It's also a bit strange because the value and meaning changes depending
on whether or not --debug is passed (short vs full hash), whether the revision
is a merge or not (one hash or two, separated by a '+'), the working directory
or not (node vs p1node), and local or not (remote defaults to tip, and never has
'+'). The equivalent string built with {rev} seems much less useful, and I
couldn't think of a reasonable name, so I left it out.
The discussion seemed to be pointing towards having a list of nodes, with more
than one entry for a merge. It seems simpler to give the nodes a name, and use
{node} for the actual commit probed, especially now that there is a virtual node
for 'wdir()'.
Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes.
I'm not sure if the plan is to fill in all of the context attributes in these
items, or if these nested items should simply be made {p1node} and {p1rev}.
I used ':' as the tag separator for consistency with {tags} in the log
templater. Likewise, bookmarks are separated by a space for consistency with
the corresponding log template.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
|
|
|
}
|
|
|
|
]
|
2010-08-12 14:49:58 +04:00
|
|
|
|
2017-06-26 03:37:16 +03:00
|
|
|
test template keywords and functions which require changectx:
|
2020-07-18 08:22:03 +03:00
|
|
|
(The Rust layer does not special handle the wdir commit hash so shortest does
|
|
|
|
not "work" here. In the future we want to change virtual commits handling to
|
|
|
|
use normal (non-special-cased) in-memory-only commits in the Rust DAG instead
|
|
|
|
of special casing them in various APIs (ex. partialmatch))
|
2017-06-26 03:37:16 +03:00
|
|
|
|
|
|
|
$ hg id -T '{rev} {node|shortest}\n'
|
2020-07-18 08:22:03 +03:00
|
|
|
2147483647 ffffffffffffffffffffffffffffffffffffffff
|
2017-06-26 03:37:16 +03:00
|
|
|
$ hg id -T '{parents % "{rev} {node|shortest} {desc}\n"}'
|
|
|
|
0 cb9a a
|
|
|
|
|
2010-08-12 14:49:58 +04:00
|
|
|
with modifications
|
|
|
|
|
|
|
|
$ echo b > a
|
|
|
|
$ hg id -n -t -b -i
|
2019-12-18 00:45:17 +03:00
|
|
|
cb9a9f314b8b+ 0+ default
|
identify: add template support
This is based on a patch proposed last year by Mathias De Maré[1], with a few
changes.
- Tags and bookmarks are now formatted lists, for more flexible queries.
- The templater is populated whether or not [-nibtB] is specified. (Plain
output is unchanged.) This seems more consistent with other templated
commands.
- The 'id' property is a string, instead of a list.
- The parents of 'wdir()' have their own list of attributes.
I left 'id' as a string because it seems very useful for generating version
info. It's also a bit strange because the value and meaning changes depending
on whether or not --debug is passed (short vs full hash), whether the revision
is a merge or not (one hash or two, separated by a '+'), the working directory
or not (node vs p1node), and local or not (remote defaults to tip, and never has
'+'). The equivalent string built with {rev} seems much less useful, and I
couldn't think of a reasonable name, so I left it out.
The discussion seemed to be pointing towards having a list of nodes, with more
than one entry for a merge. It seems simpler to give the nodes a name, and use
{node} for the actual commit probed, especially now that there is a virtual node
for 'wdir()'.
Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes.
I'm not sure if the plan is to fill in all of the context attributes in these
items, or if these nested items should simply be made {p1node} and {p1rev}.
I used ':' as the tag separator for consistency with {tags} in the log
templater. Likewise, bookmarks are separated by a space for consistency with
the corresponding log template.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
|
|
|
$ hg id -Tjson
|
|
|
|
[
|
|
|
|
{
|
|
|
|
"bookmarks": [],
|
2017-06-26 00:46:35 +03:00
|
|
|
"dirty": "+",
|
identify: add template support
This is based on a patch proposed last year by Mathias De Maré[1], with a few
changes.
- Tags and bookmarks are now formatted lists, for more flexible queries.
- The templater is populated whether or not [-nibtB] is specified. (Plain
output is unchanged.) This seems more consistent with other templated
commands.
- The 'id' property is a string, instead of a list.
- The parents of 'wdir()' have their own list of attributes.
I left 'id' as a string because it seems very useful for generating version
info. It's also a bit strange because the value and meaning changes depending
on whether or not --debug is passed (short vs full hash), whether the revision
is a merge or not (one hash or two, separated by a '+'), the working directory
or not (node vs p1node), and local or not (remote defaults to tip, and never has
'+'). The equivalent string built with {rev} seems much less useful, and I
couldn't think of a reasonable name, so I left it out.
The discussion seemed to be pointing towards having a list of nodes, with more
than one entry for a merge. It seems simpler to give the nodes a name, and use
{node} for the actual commit probed, especially now that there is a virtual node
for 'wdir()'.
Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes.
I'm not sure if the plan is to fill in all of the context attributes in these
items, or if these nested items should simply be made {p1node} and {p1rev}.
I used ':' as the tag separator for consistency with {tags} in the log
templater. Likewise, bookmarks are separated by a space for consistency with
the corresponding log template.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
|
|
|
"id": "cb9a9f314b8b+",
|
|
|
|
"node": "ffffffffffffffffffffffffffffffffffffffff",
|
2020-01-07 23:29:27 +03:00
|
|
|
"parents": [{"node": "cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b", "rev": 0}]
|
identify: add template support
This is based on a patch proposed last year by Mathias De Maré[1], with a few
changes.
- Tags and bookmarks are now formatted lists, for more flexible queries.
- The templater is populated whether or not [-nibtB] is specified. (Plain
output is unchanged.) This seems more consistent with other templated
commands.
- The 'id' property is a string, instead of a list.
- The parents of 'wdir()' have their own list of attributes.
I left 'id' as a string because it seems very useful for generating version
info. It's also a bit strange because the value and meaning changes depending
on whether or not --debug is passed (short vs full hash), whether the revision
is a merge or not (one hash or two, separated by a '+'), the working directory
or not (node vs p1node), and local or not (remote defaults to tip, and never has
'+'). The equivalent string built with {rev} seems much less useful, and I
couldn't think of a reasonable name, so I left it out.
The discussion seemed to be pointing towards having a list of nodes, with more
than one entry for a merge. It seems simpler to give the nodes a name, and use
{node} for the actual commit probed, especially now that there is a virtual node
for 'wdir()'.
Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes.
I'm not sure if the plan is to fill in all of the context attributes in these
items, or if these nested items should simply be made {p1node} and {p1rev}.
I used ':' as the tag separator for consistency with {tags} in the log
templater. Likewise, bookmarks are separated by a space for consistency with
the corresponding log template.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
2017-06-25 06:09:21 +03:00
|
|
|
}
|
|
|
|
]
|
2010-08-12 14:49:58 +04:00
|
|
|
|
|
|
|
other local repo
|
|
|
|
|
|
|
|
$ cd ..
|
|
|
|
$ hg -R test id
|
2019-12-18 00:45:17 +03:00
|
|
|
cb9a9f314b8b+
|
2012-06-21 01:41:21 +04:00
|
|
|
#if no-outer-repo
|
2010-08-12 14:49:58 +04:00
|
|
|
$ hg id test
|
|
|
|
cb9a9f314b8b+ tip
|
2012-06-21 01:41:21 +04:00
|
|
|
#endif
|
2010-08-12 14:49:58 +04:00
|
|
|
|
2020-04-10 20:56:22 +03:00
|
|
|
with remote ssh repo
|
2010-08-12 14:49:58 +04:00
|
|
|
|
|
|
|
$ cd test
|
2020-04-10 20:56:22 +03:00
|
|
|
$ hg id ssh://user@dummy/test
|
2010-08-12 14:49:58 +04:00
|
|
|
cb9a9f314b8b
|
|
|
|
|
2011-02-19 02:09:08 +03:00
|
|
|
remote with rev number?
|
|
|
|
|
2020-04-10 20:56:22 +03:00
|
|
|
$ hg id -n ssh://user@dummy/test
|
2020-01-07 23:29:27 +03:00
|
|
|
abort: can't query remote revision number or branch
|
2011-02-19 02:09:08 +03:00
|
|
|
[255]
|
|
|
|
|
|
|
|
remote with branch?
|
|
|
|
|
2020-04-10 20:56:22 +03:00
|
|
|
$ hg id -b ssh://user@dummy/test
|
2020-01-07 23:29:27 +03:00
|
|
|
abort: can't query remote revision number or branch
|
2010-09-17 02:51:32 +04:00
|
|
|
[255]
|
2011-02-18 22:25:25 +03:00
|
|
|
|
2011-03-13 16:35:17 +03:00
|
|
|
test bookmark support
|
|
|
|
|
|
|
|
$ hg bookmark Y
|
|
|
|
$ hg bookmark Z
|
|
|
|
$ hg bookmarks
|
|
|
|
Y 0:cb9a9f314b8b
|
|
|
|
* Z 0:cb9a9f314b8b
|
|
|
|
$ hg id
|
2019-12-18 00:45:17 +03:00
|
|
|
cb9a9f314b8b+ Y/Z
|
2011-03-13 16:35:17 +03:00
|
|
|
$ hg id --bookmarks
|
|
|
|
Y Z
|
|
|
|
|
|
|
|
test remote identify with bookmarks
|
|
|
|
|
2020-04-10 20:56:22 +03:00
|
|
|
$ hg id ssh://user@dummy/test
|
2011-03-13 16:35:17 +03:00
|
|
|
cb9a9f314b8b Y/Z
|
2020-04-10 20:56:22 +03:00
|
|
|
$ hg id --bookmarks ssh://user@dummy/test
|
2011-03-13 16:35:17 +03:00
|
|
|
Y Z
|
2020-04-10 20:56:22 +03:00
|
|
|
$ hg id -r . ssh://user@dummy/test
|
2011-03-13 16:35:17 +03:00
|
|
|
cb9a9f314b8b Y/Z
|
2020-04-10 20:56:22 +03:00
|
|
|
$ hg id --bookmarks -r . ssh://user@dummy/test
|
2011-03-13 16:35:17 +03:00
|
|
|
Y Z
|
|
|
|
|
2014-04-24 01:29:55 +04:00
|
|
|
test invalid lookup
|
|
|
|
|
2020-04-10 20:56:22 +03:00
|
|
|
$ hg id -r noNoNO ssh://user@dummy/test
|
2014-04-24 01:29:55 +04:00
|
|
|
abort: unknown revision 'noNoNO'!
|
|
|
|
[255]
|
|
|
|
|
2011-02-18 22:25:25 +03:00
|
|
|
Make sure we do not obscure unknown requires file entries (issue2649)
|
|
|
|
|
|
|
|
$ echo fake >> .hg/requires
|
|
|
|
$ hg id
|
2014-03-19 03:18:30 +04:00
|
|
|
abort: repository requires features unknown to this Mercurial: fake!
|
2015-09-30 23:43:49 +03:00
|
|
|
(see https://mercurial-scm.org/wiki/MissingRequirement for more information)
|
2011-02-18 22:25:25 +03:00
|
|
|
[255]
|
|
|
|
|
|
|
|
$ cd ..
|
2012-06-21 01:41:21 +04:00
|
|
|
#if no-outer-repo
|
2011-02-18 22:25:25 +03:00
|
|
|
$ hg id test
|
2014-03-19 03:18:30 +04:00
|
|
|
abort: repository requires features unknown to this Mercurial: fake!
|
2015-09-30 23:43:49 +03:00
|
|
|
(see https://mercurial-scm.org/wiki/MissingRequirement for more information)
|
2011-02-18 22:25:25 +03:00
|
|
|
[255]
|
2012-06-21 01:41:21 +04:00
|
|
|
#endif
|