Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
