sapling/tests/test-merge-default.t

152 lines
3.4 KiB
Perl
Raw Normal View History

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
created new head
$ hg up 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo e >> a
$ hg commit -me
created new head
$ hg up 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Should fail because not at a head:
$ hg merge
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
update: warn about other topological heads on bare update A concern around the user experience of Mercurial is user getting stuck on there own topological branch forever. For example, someone pulling another topological branch, missing that message in pull asking them to merge and getting stuck on there own local branch. The current way to "address" this concern was for bare 'hg update' to target the tipmost (also latest pulled) changesets and complain when the update was not linear. That way, failure to merge newly pulled changesets would result in some kind of failure. Yet the failure was quite obscure, not working in all cases (eg: commit right after pull) and the behavior was very impractical in the common case (eg: issue4673). To be able to change that behavior, we need to provide other ways to alert a user stucks on one of many topological head. We do so with an extra message after bare update: 1 other heads for branch "default" Bookmark get its own special version: 1 other divergent bookmarks for "foobar" There is significant room to improve the message itself, and we should augment it with hint about how to see theses other heads or handle the situation (see in-line comment). But having "a" message is already a significant improvement compared to the existing situation. Once we have it we can iterate on a better version of it. As having such message is an important step toward changing the default destination for update and other nicety, I would like to move forward quickly on getting such message. This was discussed during London - October 2015 Sprint.
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)
$ 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
Should fail because at tip:
$ hg merge
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
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
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
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]
(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
created new head
$ 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]