Subject: Re: [PATCH] apply: fix delete-then-new patch fail with 3way

From: Junio C Hamano <[email-masked]>
Date: Sat, 16 Oct 2021 23:08:04 -0700

"Hongren (Zenithal) Zheng" <[email-masked]> writes:

> On Sun, Oct 03, 2021 at 07:25:29PM +0800, Hongren (Zenithal) Zheng wrote:
>> For one single patch FILE containing both deletion and creation
>> of the same file, applying with three way would fail, which should not.
>>  ...

Sigh.

Jerry, it seems that the earlier "let's be more aggressive to use
--3way, instead of using it as a fallback" is turning out to be more
and more trouble than we hoped.

One thing to notice about the patch used for this test is that ...

>> +test_expect_success 'apply delete then new patch with 3way' '
>> +	git reset --hard main &&
>> +	test_write_lines 1 > delnew &&
>> +	git add delnew &&
>> +	git commit -m "delnew" &&
>> +	cat >delete-then-new.patch <<-\EOF &&
>> +	--- a/delnew
>> +	+++ /dev/null
>> +	@@ -1 +0,0 @@
>> +	-1
>> +	--- /dev/null
>> +	+++ b/delnew
>> +	@@ -0,0 +1 @@
>> +	+2
>> +	EOF

... this is clearly not a patch that was generated by Git.  We do
not show two separate patches, to delete and then to create, the
same path to express a file modification, and that is true even when
we are showing a total-rewrite patch.

In addition, the above set of two patches lack the "index" header
that records the old and new blob object name, because it is not a
patch generated by Git.  Whether 3-way is attempted before or after
the normal application, because the object names there are a crucial
ingredient for the 3-way merge logic, there is no way for it to work
at all.

>> +	# Apply must succeed.
>> +	git apply --3way delete-then-new.patch

So, one simple and safe answer would be "Don't do it, --3way is only
about Git patches."  IOW, the command is failing as designed.

To extend and automate the solution would be to see, just before
attempting to do the 3-way, if the incoming patch is a Git generated
one, and do not even bother using the 3-way logic if it is not.