# HG changeset patch
# User Pierre-Yves David <pierre-yves.david@octobus.net>
# Date 1583224051 -3600
# Node ID b8882f5d7cb49851f34600d60313671b31bce3fd
# Parent  68e14fecd82ab6bfb3283f1a56e14974816ecc76
copies-tests: update the analysis of the BD/DB cases

After thinking more about it, the current change in output between the two
merges is not due to an ambiguity, it is introduce by a bug in merge/commit
that record a wrong file history.

Fixing the bug should fix the output. In the meantime, we have a wrong behavior.

In practice the bug is not in the merge code (who does the right things), but in
the commit code (who get confused when recording the new file revision).

Differential Revision: https://phab.mercurial-scm.org/D8237

diff -r 68e14fecd82a -r b8882f5d7cb4 tests/test-copies-chain-merge.t
--- a/tests/test-copies-chain-merge.t	Fri Mar 06 11:02:02 2020 +0100
+++ b/tests/test-copies-chain-merge.t	Tue Mar 03 09:27:31 2020 +0100
@@ -195,7 +195,7 @@
 
 Merge:
 - one with change to an unrelated file
-- one deleting and recreating the change
+- one deleting and recreating the file
 
 Note:
 | In this case, the merge get conflicting information since on one side we have
@@ -294,8 +294,8 @@
   
 
 Note:
-| In this case, the merge get conflicting information since each side have a
-| different way to reach 'f'.
+| In this case, one of the merge wrongly record a merge while there is none.
+| This lead to bad copy tracing information to be dug up.
 
 final summary
 
@@ -453,11 +453,8 @@
 - one deleting and recreating the change
 
 Note:
-| In this case, the merge get conflicting information since on one side we have
-| a "brand new" d. and one the other one we have "d renamed from c (itself
-| renamed from c)".
-|
-| The current code arbitrarily pick one side
+| In this case, one of the merge wrongly record a merge while there is none.
+| This lead to bad copy tracing information to be dug up.
 
   $ hg status --copies --rev 'desc("b-1")' --rev 'desc("mBDm-0")'
   M d
@@ -475,14 +472,18 @@
   M b
   M d
 
-The recorded copy is different depending of where we started the merge from since
+The bugs makes recorded copy is different depending of where we started the merge from since
 
   $ hg manifest --debug --rev 'desc("mBDm-0")' | grep '644   d'
   0bb5445dc4d02f4e0d86cf16f9f3a411d0f17744 644   d
   $ hg manifest --debug --rev 'desc("mDBm-0")' | grep '644   d'
   b004912a8510032a0350a74daa2803dadfb00e12 644   d
 
-This second b004912a8510032a0350a74daa2803dadfb00e12 seems wrong. We should record the merge
+The 0bb5445dc4d02f4e0d86cf16f9f3a411d0f17744 entry is wrong, since the file was
+deleted on one side (then recreate) and untouched on the other side, no "merge"
+has happened. The resulting `d` file is the untouched version from branch `D`,
+not a merge.
+
   $ hg manifest --debug --rev 'desc("d-2")' | grep '644   d'
   b004912a8510032a0350a74daa2803dadfb00e12 644   d
   $ hg manifest --debug --rev 'desc("b-1")' | grep '644   d'
@@ -493,6 +494,8 @@
        1      10 b004912a8510 000000000000 000000000000
        2      15 0bb5445dc4d0 01c2f5eabdc4 b004912a8510
 
+(This `hg log` output if wrong, since no merge actually happened).
+
   $ hg log -Gfr 'desc("mBDm-0")' d
   o    15 mBDm-0 simple merge - one way]
   |\
@@ -505,8 +508,7 @@
   o  0 i-0 initial commit: a b]
   
 
-(That output seems wrong, if we had opportunity to record the merge, we should
-probably have recorded the merge).
+This `hg log` output is correct
 
   $ hg log -Gfr 'desc("mDBm-0")' d
   o  14 d-2 re-add d]