Merge recreating deleted file

Koritako Alana koritakoa at gmail.com
Sat Oct 13 01:20:21 UTC 2018


Hi all,

I am noticing unexpected behaviour when merging. I have created a test repo
to demonstrate the issue I am experiencing:
https://bitbucket.org/koritakoa/hg-merge-test/ . The commit messages have
some basic text which hopefully give some insight, but I will describe the
problem more thoroughly below:

The behaviour described below is seen in Mercurial 4.7.

I have 2 revisions: 4e0d700 (branch custom/a) and 583eb25 (branch temp/2)
which share a common ancestor: f0330b6 (branch trunk/1), in which a file
named "file2" was created. Between f0330b6 and 583eb25 (temp/2) file2 is
not modified, but file2 is deleted between f0330b6 and 4e0d700 (custom/a).
When I update to 4e0d700 (custom/a) and merge with 583eb25 (temp/2), then
the file (file2) that was previously deleted in 4e0d700 (custom/a)'s
ancestors is recreated by the merge. This merge, in which the file is
"erroneously" recreated, is committed as revision 6c4e48c in the repo
linked to above.

This is not what I expected. I expected there to be no changes introduced
by the merge committed as 6c4e48c. I expect no changes to be introduced
because 4e0d700 is already a descendant of all revisions which actually
made changes to "file2". In fact, it is already a descendant of any
revision that changed any file at all. As the person looking after
custom/a, I have already dealt with the changes introduced by revision
f0330b6. I dealt with these changes in merge 4e0d700. When I merge 583eb25,
which is the merge of an ancestor or 4e0d700 and f0330b6, I don't expect to
have to deal with the changes introduced by f0330b6 a second time.
Especially since 583eb25 does not make any modification to the changes
introduced in f0330b6.

I suppose we can say that I expect merge to pull in changes I haven't seen,
as opposed to making me deal with changes I have already seen.

Please notice that the what happened to file2 is mirrored by what happened
to file1. Except that file1 was modified in the trunk/2 branch, not deleted
as file2 was. I did this to demonstrate how merging (merge committed
as 329fce7) the result of merging two ancestors does the correct thing (or
at least what I expect) when the file was modified, not deleted.

In merge committed as 329fce7, HG sees that file1, in local, went from
"original" to "modified", while in other, it remained as "original". HG
chooses to retain it as "modified". ie. keep local.

In merge committed as 6c4e48c, HG sees that file2, in local, went from
"original" to "deleted", while in other, it remained as "original". HG
chooses to revert the file to "original". ie. keep other.

I expect HG to keep local in both merges.

Why is HG not "keeping local" in the second merge? Is my expectation
correct here? If not, please help me understand why it shouldn't keep local
for both.

TLDR:
% hg clone https://bitbucket.org/koritakoa/hg-merge-test
% cd hg-merge-test
% hg up -r 4e0d700
% hg merge -r 583eb25
% hg status
M file2
Why is hg status/hg diff not empty?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial/attachments/20181013/b86482cf/attachment.html>


More information about the Mercurial mailing list