"Hongren (Zenithal) Zheng" <i@xxxxxxxxxxx> 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.
