2010-09-11 13:44:53 +04:00
|
|
|
$ hg init
|
|
|
|
$ echo a > a
|
|
|
|
$ hg commit -A -ma
|
|
|
|
adding a
|
|
|
|
|
|
|
|
$ echo b >> a
|
|
|
|
$ hg commit -mb
|
|
|
|
|
|
|
|
$ echo c >> a
|
|
|
|
$ hg commit -mc
|
|
|
|
|
|
|
|
$ hg up 1
|
|
|
|
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ echo d >> a
|
|
|
|
$ hg commit -md
|
|
|
|
|
|
|
|
$ hg up 1
|
|
|
|
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ echo e >> a
|
|
|
|
$ hg commit -me
|
|
|
|
|
|
|
|
$ hg up 1
|
|
|
|
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
|
|
|
|
Should fail because not at a head:
|
|
|
|
|
|
|
|
$ hg merge
|
2016-02-08 16:55:58 +03:00
|
|
|
abort: working directory not at a head revision
|
|
|
|
(use 'hg update' or merge with an explicit revision)
|
2010-09-17 02:51:32 +04:00
|
|
|
[255]
|
2010-09-11 13:44:53 +04:00
|
|
|
|
|
|
|
$ hg up
|
|
|
|
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
2017-06-06 19:47:39 +03:00
|
|
|
updated to "f25cbe84d8b3: e"
|
2016-02-02 17:49:02 +03:00
|
|
|
2 other heads for branch "default"
|
2010-09-11 13:44:53 +04:00
|
|
|
|
|
|
|
Should fail because > 2 heads:
|
|
|
|
|
|
|
|
$ HGMERGE=internal:other; export HGMERGE
|
|
|
|
$ hg merge
|
|
|
|
abort: branch 'default' has 3 heads - please merge with an explicit rev
|
|
|
|
(run 'hg heads .' to see heads)
|
2010-09-17 02:51:32 +04:00
|
|
|
[255]
|
2010-09-11 13:44:53 +04:00
|
|
|
|
|
|
|
Should succeed:
|
|
|
|
|
|
|
|
$ hg merge 2
|
|
|
|
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
|
|
|
|
(branch merge, don't forget to commit)
|
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": [],
|
|
|
|
"branch": "default",
|
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": "f25cbe84d8b3+2d95304fed5d+",
|
|
|
|
"node": "ffffffffffffffffffffffffffffffffffffffff",
|
2017-06-26 03:18:55 +03:00
|
|
|
"parents": [{"node": "f25cbe84d8b320e298e7703f18a25a3959518c23", "rev": 4}, {"node": "2d95304fed5d89bc9d70b2a0d02f0d567469c3ab", "rev": 2}],
|
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
|
|
|
"tags": ["tip"]
|
|
|
|
}
|
|
|
|
]
|
2010-09-11 13:44:53 +04:00
|
|
|
$ hg commit -mm1
|
|
|
|
|
|
|
|
Should succeed - 2 heads:
|
|
|
|
|
|
|
|
$ hg merge -P
|
|
|
|
changeset: 3:ea9ff125ff88
|
|
|
|
parent: 1:1846eede8b68
|
|
|
|
user: test
|
|
|
|
date: Thu Jan 01 00:00:00 1970 +0000
|
|
|
|
summary: d
|
|
|
|
|
|
|
|
$ hg merge
|
|
|
|
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
|
|
|
|
(branch merge, don't forget to commit)
|
|
|
|
$ hg commit -mm2
|
|
|
|
|
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 -r 1 -Tjson
|
|
|
|
[
|
|
|
|
{
|
|
|
|
"bookmarks": [],
|
|
|
|
"branch": "default",
|
|
|
|
"id": "1846eede8b68",
|
|
|
|
"node": "1846eede8b6886d8cc8a88c96a687b7fe8f3b9d1",
|
|
|
|
"tags": []
|
|
|
|
}
|
|
|
|
]
|
|
|
|
|
2010-09-11 13:44:53 +04:00
|
|
|
Should fail because at tip:
|
|
|
|
|
|
|
|
$ hg merge
|
2011-12-07 21:23:01 +04:00
|
|
|
abort: nothing to merge
|
2010-09-17 02:51:32 +04:00
|
|
|
[255]
|
2010-09-11 13:44:53 +04:00
|
|
|
|
|
|
|
$ hg up 0
|
|
|
|
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
|
|
|
|
Should fail because there is only one head:
|
|
|
|
|
|
|
|
$ hg merge
|
2011-12-07 21:23:01 +04:00
|
|
|
abort: nothing to merge
|
|
|
|
(use 'hg update' instead)
|
2010-09-17 02:51:32 +04:00
|
|
|
[255]
|
2010-09-11 13:44:53 +04:00
|
|
|
|
|
|
|
$ hg up 3
|
|
|
|
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
|
|
|
|
$ echo f >> a
|
|
|
|
$ hg branch foobranch
|
|
|
|
marked working directory as branch foobranch
|
2011-12-09 00:32:44 +04:00
|
|
|
(branches are permanent and global, did you want a bookmark?)
|
2010-09-11 13:44:53 +04:00
|
|
|
$ hg commit -mf
|
|
|
|
|
|
|
|
Should fail because merge with other branch:
|
|
|
|
|
|
|
|
$ hg merge
|
|
|
|
abort: branch 'foobranch' has one head - please merge with an explicit rev
|
|
|
|
(run 'hg heads' to see all heads)
|
2010-09-17 02:51:32 +04:00
|
|
|
[255]
|
2010-09-11 13:44:53 +04:00
|
|
|
|
|
|
|
|
|
|
|
Test for issue2043: ensure that 'merge -P' shows ancestors of 6 that
|
2014-08-19 03:13:10 +04:00
|
|
|
are not ancestors of 7, regardless of where their common ancestors are.
|
2010-09-11 13:44:53 +04:00
|
|
|
|
|
|
|
Merge preview not affected by common ancestor:
|
|
|
|
|
|
|
|
$ hg up -q 7
|
|
|
|
$ hg merge -q -P 6
|
|
|
|
2:2d95304fed5d
|
|
|
|
4:f25cbe84d8b3
|
|
|
|
5:a431fabd6039
|
|
|
|
6:e88e33f3bf62
|
|
|
|
|
2015-10-15 03:47:28 +03:00
|
|
|
Test experimental destination revset
|
|
|
|
|
|
|
|
$ hg log -r '_destmerge()'
|
|
|
|
abort: branch 'foobranch' has one head - please merge with an explicit rev
|
|
|
|
(run 'hg heads' to see all heads)
|
|
|
|
[255]
|
|
|
|
|
2016-02-08 21:32:29 +03:00
|
|
|
(on a branch with a two heads)
|
|
|
|
|
|
|
|
$ hg up 5
|
|
|
|
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ echo f >> a
|
|
|
|
$ hg commit -mf
|
|
|
|
$ hg log -r '_destmerge()'
|
|
|
|
changeset: 6:e88e33f3bf62
|
|
|
|
parent: 5:a431fabd6039
|
|
|
|
parent: 3:ea9ff125ff88
|
|
|
|
user: test
|
|
|
|
date: Thu Jan 01 00:00:00 1970 +0000
|
|
|
|
summary: m2
|
|
|
|
|
|
|
|
|
|
|
|
(from the other head)
|
|
|
|
|
|
|
|
$ hg log -r '_destmerge(e88e33f3bf62)'
|
|
|
|
changeset: 8:b613918999e2
|
|
|
|
tag: tip
|
|
|
|
parent: 5:a431fabd6039
|
|
|
|
user: test
|
|
|
|
date: Thu Jan 01 00:00:00 1970 +0000
|
|
|
|
summary: f
|
|
|
|
|
|
|
|
|
|
|
|
(from unrelated branch)
|
|
|
|
|
|
|
|
$ hg log -r '_destmerge(foobranch)'
|
|
|
|
abort: branch 'foobranch' has one head - please merge with an explicit rev
|
|
|
|
(run 'hg heads' to see all heads)
|
|
|
|
[255]
|