sapling/tests/test-conflict.t

298 lines
5.9 KiB
Perl
Raw Normal View History

2010-08-12 15:02:59 +04:00
$ hg init
$ cat << EOF > a
> Small Mathematical Series.
> One
> Two
> Three
> Four
> Five
> Hop we are done.
> EOF
2010-08-12 15:02:59 +04:00
$ hg add a
$ hg commit -m ancestor
$ cat << EOF > a
> Small Mathematical Series.
> 1
> 2
> 3
> 4
> 5
> Hop we are done.
> EOF
$ hg commit -m branch1
2010-08-12 15:02:59 +04:00
$ hg co 0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat << EOF > a
> Small Mathematical Series.
> 1
> 2
> 3
> 6
> 8
> Hop we are done.
> EOF
$ hg commit -m branch2
2010-08-12 15:02:59 +04:00
$ hg merge 1
merging a
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
2010-08-12 15:02:59 +04:00
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
2010-09-17 02:51:32 +04:00
[1]
2010-08-12 15:02:59 +04:00
$ hg id
618808747361+c0c68e4fe667+ tip
2010-08-12 15:02:59 +04:00
$ echo "[commands]" >> $HGRCPATH
$ echo "status.verbose=true" >> $HGRCPATH
$ hg status
M a
? a.orig
# The repository is in an unfinished *merge* state.
# Unresolved merge conflicts:
#
# a
#
# To mark files as resolved: hg resolve --mark FILE
# To continue: hg commit
# To abort: hg update --clean . (warning: this will discard uncommitted changes)
2010-08-12 15:02:59 +04:00
$ cat a
Small Mathematical Series.
1
2
3
<<<<<<< working copy: 618808747361 - test: branch2
6
8
2010-08-12 15:02:59 +04:00
=======
4
5
>>>>>>> merge rev: c0c68e4fe667 - test: branch1
Hop we are done.
2010-08-12 15:02:59 +04:00
$ hg status --config commands.status.verbose=0
2010-08-12 15:02:59 +04:00
M a
? a.orig
Verify custom conflict markers
$ hg up -q --clean .
$ cat <<EOF >> .hg/hgrc
> [ui]
> mergemarkertemplate = '{author} {rev}'
> EOF
$ hg merge 1
merging a
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
[1]
$ cat a
Small Mathematical Series.
1
2
3
<<<<<<< working copy: test 2
6
8
=======
4
5
>>>>>>> merge rev: test 1
Hop we are done.
Verify line splitting of custom conflict marker which causes multiple lines
$ hg up -q --clean .
$ cat >> .hg/hgrc <<EOF
> [ui]
> mergemarkertemplate={author} {rev}\nfoo\nbar\nbaz
> EOF
$ hg -q merge 1
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
[1]
$ cat a
Small Mathematical Series.
1
2
3
<<<<<<< working copy: test 2
6
8
=======
4
5
>>>>>>> merge rev: test 1
Hop we are done.
Verify line trimming of custom conflict marker using multi-byte characters
$ hg up -q --clean .
$ $PYTHON <<EOF
> fp = open('logfile', 'w')
> fp.write('12345678901234567890123456789012345678901234567890' +
> '1234567890') # there are 5 more columns for 80 columns
>
> # 2 x 4 = 8 columns, but 3 x 4 = 12 bytes
> fp.write(u'\u3042\u3044\u3046\u3048'.encode('utf-8'))
>
> fp.close()
> EOF
$ hg add logfile
$ hg --encoding utf-8 commit --logfile logfile
$ cat >> .hg/hgrc <<EOF
> [ui]
> mergemarkertemplate={desc|firstline}
> EOF
$ hg -q --encoding utf-8 merge 1
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
[1]
$ cat a
Small Mathematical Series.
1
2
3
<<<<<<< working copy: 1234567890123456789012345678901234567890123456789012345...
6
8
=======
4
5
>>>>>>> merge rev: branch1
Hop we are done.
Verify basic conflict markers
$ hg up -q --clean 2
$ printf "\n[ui]\nmergemarkers=basic\n" >> .hg/hgrc
$ hg merge 1
merging a
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
[1]
$ cat a
Small Mathematical Series.
1
2
3
<<<<<<< working copy
6
8
=======
4
5
>>>>>>> merge rev
Hop we are done.
merge: add an internal:merge3 tool This variant gives access to a feature already present in ``internal:merge``: displaying merge base content. In the basic merge (calling ``hg merge``) case, including more context to the merge markers is an interesting addition. But this extra information is the only viable option in case conflict from grafting (, rebase, etc…). When grafting ``source`` on ``destination``, the parent of ``source`` is used as the ``base``. When all three changesets add content in the same location, the marker for ``source`` will contains both ``base`` and ``source`` content. Without the content of base exposed, there is no way for the user to discriminate content coming from ``base`` and content commit from ``source``. Practical example (all addition are in the same place): * ``destination`` adds ``Dest-Content`` * ``base`` adds ``Base-Content`` * ``source`` adds ``Src-Content`` Grafting ``source`` on ``destination`` will produce the following conflict: <<<<<<< destination Dest-Content ======= Base-Content Src-Content >>>>>>> source This that case there is no way to distinct ``base`` from ``source``. As a result content from ``base`` are likely to slip in the resolution result. However, adding the base make the situation very clear: <<<<<<< destination Dest-Content ||||||| base Base-Content ======= base Base-Content Src-Content >>>>>>> source Once the base is added, the addition from the grafted changeset is made clear. User can compare the content from ``base`` and ``source`` to make an enlightened decision during merge resolution.
2014-08-06 01:58:45 +04:00
internal:merge3
$ hg up -q --clean .
$ hg merge 1 --tool internal:merge3
merging a
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
merge: add an internal:merge3 tool This variant gives access to a feature already present in ``internal:merge``: displaying merge base content. In the basic merge (calling ``hg merge``) case, including more context to the merge markers is an interesting addition. But this extra information is the only viable option in case conflict from grafting (, rebase, etc…). When grafting ``source`` on ``destination``, the parent of ``source`` is used as the ``base``. When all three changesets add content in the same location, the marker for ``source`` will contains both ``base`` and ``source`` content. Without the content of base exposed, there is no way for the user to discriminate content coming from ``base`` and content commit from ``source``. Practical example (all addition are in the same place): * ``destination`` adds ``Dest-Content`` * ``base`` adds ``Base-Content`` * ``source`` adds ``Src-Content`` Grafting ``source`` on ``destination`` will produce the following conflict: <<<<<<< destination Dest-Content ======= Base-Content Src-Content >>>>>>> source This that case there is no way to distinct ``base`` from ``source``. As a result content from ``base`` are likely to slip in the resolution result. However, adding the base make the situation very clear: <<<<<<< destination Dest-Content ||||||| base Base-Content ======= base Base-Content Src-Content >>>>>>> source Once the base is added, the addition from the grafted changeset is made clear. User can compare the content from ``base`` and ``source`` to make an enlightened decision during merge resolution.
2014-08-06 01:58:45 +04:00
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
[1]
$ cat a
Small Mathematical Series.
<<<<<<< working copy
merge: add an internal:merge3 tool This variant gives access to a feature already present in ``internal:merge``: displaying merge base content. In the basic merge (calling ``hg merge``) case, including more context to the merge markers is an interesting addition. But this extra information is the only viable option in case conflict from grafting (, rebase, etc…). When grafting ``source`` on ``destination``, the parent of ``source`` is used as the ``base``. When all three changesets add content in the same location, the marker for ``source`` will contains both ``base`` and ``source`` content. Without the content of base exposed, there is no way for the user to discriminate content coming from ``base`` and content commit from ``source``. Practical example (all addition are in the same place): * ``destination`` adds ``Dest-Content`` * ``base`` adds ``Base-Content`` * ``source`` adds ``Src-Content`` Grafting ``source`` on ``destination`` will produce the following conflict: <<<<<<< destination Dest-Content ======= Base-Content Src-Content >>>>>>> source This that case there is no way to distinct ``base`` from ``source``. As a result content from ``base`` are likely to slip in the resolution result. However, adding the base make the situation very clear: <<<<<<< destination Dest-Content ||||||| base Base-Content ======= base Base-Content Src-Content >>>>>>> source Once the base is added, the addition from the grafted changeset is made clear. User can compare the content from ``base`` and ``source`` to make an enlightened decision during merge resolution.
2014-08-06 01:58:45 +04:00
1
2
3
6
8
||||||| base
One
Two
Three
Four
Five
=======
1
2
3
4
5
>>>>>>> merge rev
merge: add an internal:merge3 tool This variant gives access to a feature already present in ``internal:merge``: displaying merge base content. In the basic merge (calling ``hg merge``) case, including more context to the merge markers is an interesting addition. But this extra information is the only viable option in case conflict from grafting (, rebase, etc…). When grafting ``source`` on ``destination``, the parent of ``source`` is used as the ``base``. When all three changesets add content in the same location, the marker for ``source`` will contains both ``base`` and ``source`` content. Without the content of base exposed, there is no way for the user to discriminate content coming from ``base`` and content commit from ``source``. Practical example (all addition are in the same place): * ``destination`` adds ``Dest-Content`` * ``base`` adds ``Base-Content`` * ``source`` adds ``Src-Content`` Grafting ``source`` on ``destination`` will produce the following conflict: <<<<<<< destination Dest-Content ======= Base-Content Src-Content >>>>>>> source This that case there is no way to distinct ``base`` from ``source``. As a result content from ``base`` are likely to slip in the resolution result. However, adding the base make the situation very clear: <<<<<<< destination Dest-Content ||||||| base Base-Content ======= base Base-Content Src-Content >>>>>>> source Once the base is added, the addition from the grafted changeset is made clear. User can compare the content from ``base`` and ``source`` to make an enlightened decision during merge resolution.
2014-08-06 01:58:45 +04:00
Hop we are done.
Add some unconflicting changes on each head, to make sure we really
are merging, unlike :local and :other
$ hg up -C
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
updated to "e0693e20f496: 123456789012345678901234567890123456789012345678901234567890????"
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
1 other heads for branch "default"
$ printf "\n\nEnd of file\n" >> a
$ hg ci -m "Add some stuff at the end"
$ hg up -r 1
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ printf "Start of file\n\n\n" > tmp
$ cat a >> tmp
$ mv tmp a
$ hg ci -m "Add some stuff at the beginning"
Now test :merge-other and :merge-local
$ hg merge
merging a
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
1 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
[1]
$ hg resolve --tool :merge-other a
merging a
(no more unresolved files)
$ cat a
Start of file
Small Mathematical Series.
1
2
3
6
8
Hop we are done.
End of file
$ hg up -C
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
updated to "18b51d585961: Add some stuff at the beginning"
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
1 other heads for branch "default"
$ hg merge --tool :merge-local
merging a
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ cat a
Start of file
Small Mathematical Series.
1
2
3
4
5
Hop we are done.
End of file