Re: Lost file after git merge

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Thu, Jul 28 2022, Laďa Tesařík wrote:
>
>> 1. I added a file called 'new_file' to a master branch.
>> 2. Then I created branch feature/2 and deleted the file in master
>> 3. Then I deleted the file in branch feature/2 as well.
>> 4. I created 'new_file' on branch feature/2 again.

It heavily depends on how this creation is done, i.e. what went into
the created file.  Imagine that a file existed with content A at
commit 0, both commits 1 and 2 removed it on their forked history,
and then commit 3 added exactly the same content A to the same path:

          1---3
         /     \
    ----0---2---4---->

When you are about to merge 2 and 3 to create 4, what would a
three-way merge see?

    0 had content A at path P
    2 said "no we do not want content A at path P"
    3 said "we are happy with content A at path P"

So the net result is that 0-->3 "one side did not touch A at P" and
0-->2 "one side removed A at P".  

Three-way merge between X and Y is all about taking what X did if Y
didn't have any opinion on what X touched.  This is exactly that
case.  The history 0--->3 didn't have any opinion on what should be
in P or whether P should exist, and that is why there is no change
between these two endpoints.  The history 0--->2 does care---it feels
that it is detrimental to the project to have P hence it removed.

So the end result will remove P, if 3 added identical content as
existed at 0 and removed at 1.

If 3 added something different, then the picture becomes entirely
different.  The history 0--->3 no longer has "no opinion".  It
strongly believes that P having content A at 0 was wrong, and it
should have content B, hence it changed it.  Now when that opinion
collides with the opinion of the history 0--->2 that says it is
wrong to have content A at path P, the person who is creating the
merge at 4 needs to think and resolve.