merge: demonstrate that directory renames can lose local file content
When a directory has been renamed on the local branch and a file has
been added in the old location on a remote branch, we move that new
file to the new location. Unfortunately, if there is already a file
there, we overwrite it with the contents from the remote branch. For
untracked local files, we should probably abort, and for tracked local
files, we should merge the contents. To start with, let's add a test
to demonstrate the breakage. Also note that while files merged in from
a remote branch are normally (and unintuitively) reported as modified,
these files are reported as added.
--- a/tests/test-rename-dir-merge.t Fri Nov 28 03:09:19 2014 +0100
+++ b/tests/test-rename-dir-merge.t Tue Dec 02 13:28:07 2014 -0800
@@ -105,6 +105,41 @@
$ hg debugrename b/c
b/c renamed from a/c:354ae8da6e890359ef49ade27b68bbc361f3ca88 (glob)
+Local directory rename with conflicting file added in remote source directory
+and untracked in local target directory.
+
+BROKEN: the uncommitted file is overwritten; we should abort
+
+ $ hg co -qC 1
+ $ echo local > b/c
+ $ hg merge 2
+ 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+ (branch merge, don't forget to commit)
+ $ hg st -C
+ A b/c
+ a/c
+ ? a/d
+ $ cat b/c
+ baz
+
+Local directory rename with conflicting file added in remote source directory
+and committed in local target directory.
+
+BROKEN: the local file is overwritten; it should be merged
+
+ $ hg co -qC 1
+ $ echo local > b/c
+ $ hg add b/c
+ $ hg commit -qm 'new file in target directory'
+ $ hg merge 2
+ 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+ (branch merge, don't forget to commit)
+ $ hg st -C
+ A b/c
+ a/c
+ ? a/d
+ $ cat b/c
+ baz
Second scenario with two repos: