sapling/eden/scm/tests/test-conflict.t

375 lines
7.7 KiB
Perl
Raw Normal View History

#chg-compatible
$ hg init repo
$ cd repo
$ 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
$ hg co 'desc(ancestor)'
2010-08-12 15:02:59 +04:00
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 'desc(branch1)'
2010-08-12 15:02:59 +04:00
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+
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} {node}'
> EOF
$ hg merge 'desc(branch1)'
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 6188087473610f9c9c11296d35620d7e0d35f796
6
8
=======
4
5
>>>>>>> merge rev: test c0c68e4fe667f80c031c0e5871bcb12fae657a57
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} {node}\nfoo\nbar\nbaz
> EOF
$ hg -q merge 'desc(branch1)'
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
[1]
$ cat a
Small Mathematical Series.
1
2
3
<<<<<<< working copy: test 6188087473610f9c9c11296d35620d7e0d35f796
6
8
=======
4
5
>>>>>>> merge rev: test c0c68e4fe667f80c031c0e5871bcb12fae657a57
Hop we are done.
Verify line trimming of custom conflict marker using multi-byte characters
$ hg up -q --clean .
$ $PYTHON <<EOF
> fp = open('logfile', 'wb')
> fp.write(b'12345678901234567890123456789012345678901234567890' +
> b'1234567890') # there are 5 more columns for 80 columns
>
> # 2 x 4 = 8 columns, but 3 x 4 = 12 bytes
> fp.write(b'\xe3\x81\x82\xe3\x81\x84\xe3\x81\x86\xe3\x81\x88')
>
> 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 'desc(branch1)'
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 'desc(branch2)'
$ printf "\n[ui]\nmergemarkers=basic\n" >> .hg/hgrc
$ hg merge 'desc(branch1)'
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 'desc(branch1)' --tool internal:merge3
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
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
encoding: replace 'ascii' with 'utf-8' automatically Summary: `ascii` was used as the default / fallback, which is not a user-friendly choice. Nowadays utf-8 dominates: - Rust stdlib is utf-8. - Ruby since 1.9 is utf-8 by default. - Python 3 is unicode by default. - Windows 10 adds utf-8 code page. Given the fact that: - Our CI sets HGENCODING to utf-8 - Nuclide passes `--encoding=utf-8` to every command. - Some people have messed up with `LC_*` and complained about hg crashes. - utf-8 is a super set of ascii, nobody complains that they want `ascii` encoding and the `utf-8` encoding messed their setup up. Let's just use `utf-8` as the default encoding. More aggressively, if someone sets `ascii` as the encoding, it's almost always a mistake. Auto-correct that to `utf-8` too. This should also make future integration with Rust easier (where it's enforced utf-8 and does not have an option to change the encoding). In the future we might just drop the flexibility of choosing customized encoding, so this diff autofixes `ascii` to `utf-8`, instead of allowing `ascii` to be set. We cannot enforce `utf-8` yet, because of Windows. Here is our encoding strategy vs the upstream's: | item | upstream | | ours | ours | | | current | ideal | current | ideal | | CLI argv | bytes | bytes | utf-8 [1] | utf-8 | | path | bytes | auto [3] | migrating [2] | utf-8 | | commit message | utf-8 | utf-8 | utf-8 | utf-8 | | bookmark name | utf-8 | utf-8 | utf-8 | utf-8 | | file content | bytes | bytes | bytes | bytes | [1]: Argv was accidentally enforced utf-8 for command-line arguments by a Rust wrapper. But it simplified a lot of things and is kind of ok: everything that can be passed as CLI arguments are utf-8: -M commit message, -b bookmark, paths, etc. There is no "file content" passed via CLI arguments. [2]: Path is controversial, because it's possible for systems to have non-utf8 paths. The upstream behavior is incorrect if a repo gets shared among different encoding systems (ex. both Linux and Windows). We have to know the encoding of paths to be able to convert them suitable for the local system. One way is to enforce UTF-8 for paths. The other is to keep encoding information stored with individual paths (like Ruby strings). The UTF-8 approach is much simpler with the tradeoff that non-utf-8 paths become unsupported, which seems to be a reasonable trade-off. [3]: See https://www.mercurial-scm.org/wiki/WindowsUTF8Plan. Reviewed By: singhsrb Differential Revision: D17098991 fbshipit-source-id: c0ff1e586a887233bd43cdb854fb3538aa9b70c2
2019-09-13 01:05:08 +03:00
updated to "e0693e20f496: 123456789012345678901234567890123456789012345678901234567890\xe3\x81\x82\xe3\x81\x84\xe3\x81\x86\xe3\x81\x88" (esc)
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 'desc(branch1)'
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
mergetools: add new conflict marker format with diffs in Summary: Written by Martin von Zweigbergk at https://phab.mercurial-scm.org/D9551, or https://www.mercurial-scm.org/repo/hg/rev/bdc2bf68f19e. He suggested it and it's a useful feature. I did minor compatibility changes (encoding, avoid rev numbers, foo_bar -> foobar). Original commit message: I use 3-way conflict markers. Often when I resolve them, I manually compare one the base with one side and apply the differences to the other side. That can be hard when the conflict marker is large. This patch introduces a new type of conflict marker, which I'm hoping will make it easier to resolve conflicts. The new format uses `<<<<<<<` and `>>>>>>>` to open and close the markers, just like our existing 2-way and 3-way conflict markers. Instead of having 2 or 3 snapshots (left+right or left+base+right), it has a sequence of diffs. A diff looks like this: ``` ------- base +++++++ left a -b +c d ``` A diff that adds one side ("diff from nothing") has a `=======` header instead and does not have have `+` prefixed on its lines. A regular 3-way merge can be viewed as adding one side plus a diff between the base and the other side. It thus has two ways of being represented, depending on which side is being diffed: ``` <<<<<<< ======= left contents on left ------- base +++++++ right contents on -left +right >>>>>>> ``` or ``` <<<<<<< ------- base +++++++ left contents on -right +left ======= right contents on right >>>>>>> ``` I've made it so the new merge tool tries to pick a version that has the most common lines (no difference in the example above). I've called the new tool "mergediff" to stick to the convention of starting with "merge" if the tool tries a regular 3-way merge. The idea came from my pet VCS (placeholder name `jj`), which has support for octopus merges and other ways of ending up with merges of more than 3 versions. I wanted to be able to represent such conflicts in the working copy and therefore thought of this format (although I have not yet implemented it in my VCS). I then attended a meeting with Larry McVoy, who said BitKeeper has an option (`bk smerge -g`) for showing a similar format, which reminded me to actually attempt this in Mercurial. Reviewed By: DurhamG Differential Revision: D26947920 fbshipit-source-id: 8b4446862897ff9a6dfdf5a2e35617d4db09e883
2021-03-11 04:23:28 +03:00
internal:mergediff
$ hg co -C 'desc(branch1)'
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ cat << EOF > a
> Small Mathematical Series.
> 1
> 2
> 3
> 4
> 4.5
> 5
> Hop we are done.
> EOF
$ hg co -m 'desc(branch2)' -t internal:mergediff
merging a
warning: 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
[1]
$ cat a
Small Mathematical Series.
1
2
3
<<<<<<<
------- base
+++++++ working copy
4
+4.5
5
======= destination
6
8
>>>>>>>
Hop we are done.
Test the same thing as above but modify a bit more so we instead get the working
copy in full and the diff from base to destination.
$ hg co -C 'desc(branch1)'
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat << EOF > a
> Small Mathematical Series.
> 1
> 2
> 3.5
> 4.5
> 5.5
> Hop we are done.
> EOF
$ hg co -m 'desc(branch2)' -t internal:mergediff
merging a
warning: 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
[1]
$ cat a
Small Mathematical Series.
1
2
<<<<<<<
======= working copy
3.5
4.5
5.5
------- base
+++++++ destination
3
-4
-5
+6
+8
>>>>>>>
Hop we are done.