Multiple cases above explicitely test cases where content are the same on both side during merge. In this section we will introduce variants for theses cases where new change are introduced to these file content during the merges.
Subcase: merge has same initial content on both side, but merge introduced a change
@ mEA-change-m-0 merge with file update and copies info on both side - A side: rename d to f, E side: b to f, (same content for f in parent) - the other way
|\
+---o mAE-change-m-0 merge with file update and copies info on both side - A side: rename d to f, E side: b to f, (same content for f in parent) - one way
| |/
| o e-2 g -move-> f
| |
| o e-1 b -move-> g
| |
o | a-2: e -move-> f
| |
o | a-1: d -move-> e
|/
o i-2: c -move-> d
|
o i-1: a -move-> c
|
o i-0 initial commit: a b h
Decision from previous merge are properly chained with later merge
$ hg ci -m 'j-1:unrelatedchanges(basedonthe"a"seriesofchanges)'
...
...
@@ -1001,6 +1055,7 @@
l-1: unrelated changes (based on "c" changes)
mABm-0 simple merge - A side: multiple renames, B side: unrelated update - the other way
mAE,Km: chained merges (conflict -> simple) - same content everywhere
mAE-change-m-0 merge with file update and copies info on both side - A side: rename d to f, E side: b to f, (same content for f in parent) - one way
mAEm-0 merge with copies info on both side - A side: rename d to f, E side: b to f, (same content for f) - one way
mBAm-0 simple merge - A side: multiple renames, B side: unrelated update - one way
mBC+revert,Lm: chained merges (salvaged -> simple) - same content (when the file exists)
...
...
@@ -1018,6 +1073,7 @@
mDBm-0 simple merge - B side: unrelated update, D side: delete and recreate a file (with different content) - the other way
mDGm-0 actual content merge, copies on one side - D side: delete and re-add (different content), G side: update content - one way
mEA,Jm: chained merges (conflict -> simple) - same content everywhere
mEA-change-m-0 merge with file update and copies info on both side - A side: rename d to f, E side: b to f, (same content for f in parent) - the other way
mEAm-0 merge with copies info on both side - A side: rename d to f, E side: b to f, (same content for f) - the other way
mFBm-0 simple merge - B side: unrelated change, F side: overwrite d with a copy (from h->i->d) - the other way
mFG,Om: chained merges (copy-overwrite -> simple) - same content
...
...
@@ -1278,6 +1334,16 @@
1 sidedata entries
entry-0014 size 4
'\x00\x00\x00\x00'
##### revision "mAE-change-m-0 merge with file update and copies info on both side - A side" #####
o mEA-change-m-0 merge with file update and copies info on both side - A side: rename d to f, E side: b to f, (same content for f in parent) - the other way
|\
+---o mAE-change-m-0 merge with file update and copies info on both side - A side: rename d to f, E side: b to f, (same content for f in parent) - one way
| |/
| o e-2 g -move-> f
| |
| o e-1 b -move-> g
| |
o | a-2: e -move-> f
| |
o | a-1: d -move-> e
|/
o i-2: c -move-> d
|
o i-1: a -move-> c
|
o i-0 initial commit: a b h
#if no-changeset
$ hg manifest --debug --rev 'desc("mAE-change-m-0")' | grep '644 f'
2f649fba7eb284e720d02b61f0546fcef694c045 644 f
$ hg manifest --debug --rev 'desc("mEA-change-m-0")' | grep '644 f'
774e7c1637d536b99e2d8ef16fd731f87a82bd09 644 f
$ hg manifest --debug --rev 'desc("a-2")' | grep '644 f'
b76eb76580df486c3d51d63c5c210d4dd43a8ac7 644 f
$ hg manifest --debug --rev 'desc("e-2")' | grep '644 f'
e8825b386367b29fec957283a80bb47b47483fe1 644 f
$ hg debugindex f | ../no-linkrev
rev linkrev nodeid p1 p2
0 * b76eb76580df 000000000000 000000000000
1 * e8825b386367 000000000000 000000000000
2 * 2ff93c643948 b76eb76580df e8825b386367
3 * 2f649fba7eb2 b76eb76580df e8825b386367
4 * 774e7c1637d5 e8825b386367 b76eb76580df
#else
$ hg manifest --debug --rev 'desc("mAE-change-m-0")' | grep '644 f'
d3613c1ec8310a812ac4268fd853ac576b6caea5 644 f
$ hg manifest --debug --rev 'desc("mEA-change-m-0")' | grep '644 f'
05e03c868bbcab4a649cb33a238d7aa07398a469 644 f
$ hg manifest --debug --rev 'desc("a-2")' | grep '644 f'
ae258f702dfeca05bf9b6a22a97a4b5645570f11 644 f
$ hg manifest --debug --rev 'desc("e-2")' | grep '644 f'
ae258f702dfeca05bf9b6a22a97a4b5645570f11 644 f
$ hg debugindex f | ../no-linkrev
rev linkrev nodeid p1 p2
0 * ae258f702dfe 000000000000 000000000000
1 * d3613c1ec831 ae258f702dfe 000000000000
2 * 05e03c868bbc ae258f702dfe 000000000000
#endif
# Here the filelog based implementation is not looking at the rename
# information (because the file exist on both side). However the changelog
# based on works fine. We have different output.
$ hg status --copies --rev 'desc("a-2")' --rev 'desc("mAE-change-m-0")'
M f
b (no-filelog !)
R b
$ hg status --copies --rev 'desc("a-2")' --rev 'desc("mEA-change-m-0")'
M f
b (no-filelog !)
R b
$ hg status --copies --rev 'desc("e-2")' --rev 'desc("mAE-change-m-0")'
M f
d (no-filelog !)
R d
$ hg status --copies --rev 'desc("e-2")' --rev 'desc("mEA-change-m-0")'
M f
d (no-filelog !)
R d
$ hg status --copies --rev 'desc("i-2")' --rev 'desc("a-2")'
A f
d
R d
$ hg status --copies --rev 'desc("i-2")' --rev 'desc("e-2")'
A f
b
R b
# From here, we run status against revision where both source file exists.
#
# The filelog based implementation picks an arbitrary side based on revision
# numbers. So the same side "wins" whatever the parents order is. This is
# sub-optimal because depending on revision numbers means the result can be
# different from one repository to the next.
#
# The changeset based algorithm use the parent order to break tie on conflicting
# information and will have a different order depending on who is p1 and p2.
# That order is stable accross repositories. (data from p1 prevails)
$ hg status --copies --rev 'desc("i-2")' --rev 'desc("mAE-change-m-0")'
A f
d
R b
R d
$ hg status --copies --rev 'desc("i-2")' --rev 'desc("mEA-change-m-0")'
A f
d (filelog !)
b (no-filelog !)
R b
R d
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mAE-change-m-0")'
A f
a
R a
R b
$ hg status --copies --rev 'desc("i-0")' --rev 'desc("mEA-change-m-0")'
A f
a (filelog !)
b (no-filelog !)
R a
R b
Decision from previous merge are properly chained with later merge