Merge recreating deleted file

[Koritako Alana]

On Sat, 13 Oct 2018 at 03:20, Koritako Alana <koritakoa at gmail.com> wrote:
>
> 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?

Hi All,

Testing across different versions of Mercurial shows that this
behaviour has changed between different versions:

I tested with the latest release in each major.minor combination of
Mercurial. eg. 2.6.3, not 2.6 or 2.6.1. The earliest version I tested
was 1.1.2 since before that there was no `hg resolve` and I'm too lazy
to change my test script.

In Mercurial versions 1.1.2 to 2.5.4 I get the behaviour I expect.
file2 is not recreated. It is kept as deleted. (Keep local behaviour)

In Mercurial versions 2.6.3 to 3.1.2 it is considered a merge conflict.

In Mercurial versions 3.2.4 to 4.7.2 file2 is recreated/resurrected.
(Keep other behaviour).

I can post the full logs if anyone is interested.

I am not sure what the correct behaviour here is, if this is a bug or
not or, indeed, how to check what the correct behaviour is. I am
hesitant to report a bug in bugzilla in case the current behaviour is
intended. I'll give it a week and then open a bz ticket if I don't
hear anything.

Cheers,
Koritako