Re: Lost file after git merge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 28.07.22 um 19:11 schrieb Junio C Hamano:
> Æ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 last sentence is not necessarily true.  You could also say that
0--->3 cared so much about path P having content A that it brought it
back from the void.  Determining whether a de-facto revert
- intended to return to an uncaring state of "take whatever main has" or
- meant to choose *that* specific content which incidentally is on main
is not possible from the snapshots at the merge point alone, I think.

Checking if 0...3 touched P and leaving that path unmerged out of
caution shouldn't be terribly expensive.

> 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.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux