view tests/test-merge-revert2.out @ 5228:8050f13772f6

Fix theoretical issue in filecommit.

If the file was copied, we don't want to reuse the original entry.

I think this is mostly a theoretical issue - when there are copies,
fp1 == nullid, so it's very unlikely that the fl.cmp(fp1, t) would
think the file was unmodified.  In any case, if there was a copy,
we should forcefully create a new entry.

1:f248da0d4c3e
0:9eca13a34789
f248da0d4c3e tip
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
9eca13a34789
9eca13a34789+
reverting file1
9eca13a34789
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
f248da0d4c3e tip
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
warning: conflicts during merge.
merging file1
merging file1 failed!
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
There are unresolved merges with locally modified files.
You can redo the full merge using:
  hg update 0
  hg update 1
diff -r f248da0d4c3e file1
--- a/file1
+++ b/file1
@@ -1,3 +1,7 @@ added file1
 added file1
 another line of text
+<<<<<<< my
+changed file1 different
+=======
 changed file1
+>>>>>>> other
M file1
f248da0d4c3e+ tip
reverting file1
f248da0d4c3e tip
f248da0d4c3e tip
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
f248da0d4c3e tip