Re: Lost file after git merge
- From
René Scharfe <l.s.r@web.de>
- Date
- Jul 29, 2022, 20:23 UTC
- Message-ID
- <701c318c-1a1b-1793-90e8-807cf97dc948@web.de>
- In-Reply-To
- <xmqqilnhcgd7.fsf@gitster.g>
Am 28.07.22 um 19:11 schrieb Junio C Hamano:
Show 33 quoted lines
> Æ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 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.
Show 13 quoted lines
> 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.