git apply --3way behaves abnormally when the patch contains binary changes.

git apply --3way behaves abnormally when the patch contains binary changes.

[lilinchao]

I see the latest change about `git apply --3way` is 923cd87, but it doesn't seem to have been fully tested
(in t4108-apply-threeway.sh).
On latest Git version 2.32.0, consider test case below:
"
test_expect_success 'apply binary file patch with --3way' '
        # 1. on new branch, commit binary file 
        git checkout -b left &&
        cat "$TEST_DIRECTORY"/test-binary-1.png >bin.png &&
        git add bin.png &&
        git commit -m "add binary file" &&

        # 2. based on left_bin branch, make any change, and commit
        git checkout -b right &&
        cat bin.png bin.png > bin.png &&
        git add bin.png &&
        git commit -m "update binary file" &&

        # 3. make patch
        git diff --binary left..right >bin.diff &&
        # apply --3way, and it will fail
        test_must_fail git apply --index --3way bin.diff
'
"

But  "git apply --index --3way bin.diff" will not faill on Git version 2.31.0.

Re: git apply --3way behaves abnormally when the patch contains binary changes.

[Jerry Zhang]

On Tue, Jul 27, 2021 at 7:07 AM lilinchao@oschina.cn
<lilinchao@oschina.cn> wrote:
>
> I see the latest change about `git apply --3way` is 923cd87, but it doesn't seem to have been fully tested
> (in t4108-apply-threeway.sh).
> On latest Git version 2.32.0, consider test case below:
> "
> test_expect_success 'apply binary file patch with --3way' '
>         # 1. on new branch, commit binary file
>         git checkout -b left &&
>         cat "$TEST_DIRECTORY"/test-binary-1.png >bin.png &&
>         git add bin.png &&
>         git commit -m "add binary file" &&
>
>         # 2. based on left_bin branch, make any change, and commit
>         git checkout -b right &&
>         cat bin.png bin.png > bin.png &&
>         git add bin.png &&
>         git commit -m "update binary file" &&
>
>         # 3. make patch
>         git diff --binary left..right >bin.diff &&
>         # apply --3way, and it will fail
>         test_must_fail git apply --index --3way bin.diff
> '
> "
>
> But  "git apply --index --3way bin.diff" will not faill on Git version 2.31.0.
Are you sure? I checked out to "commit
a5828ae6b52137b913b978e16cd2334482eb4c1f (HEAD, tag: v2.31.0)" and
rebuilt and ran your test snippet and it still failed.

This was the message from the failure on 2.31.0
"error: the patch applies to 'bin.png'
(e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the
current contents.
Falling back to three-way merge...
warning: Cannot merge binary files: bin.png (ours vs. theirs)
Applied patch to 'bin.png' with conflicts.
U bin.png"

Versus the message on 2.32.0
"warning: Cannot merge binary files: bin.png (ours vs. theirs)
Applied patch to 'bin.png' with conflicts.
U bin.png"

So the failure messaging is different but it returns 1 both times. Is
there a difference between how we're testing?

I did have to modify your test to add
test_expect_success 'apply binary file patch with --3way' '
       # 1. on new branch, commit binary file
       git checkout -b left &&
+       git reset --hard &&

If this behavior is important I'd urge you to add this test to the suite.
>
>

Re: git apply --3way behaves abnormally when the patch contains binary changes.

[Junio C Hamano]

Jerry Zhang <jerry@skydio.com> writes:

>>         # 2. based on left_bin branch, make any change, and commit
>>         git checkout -b right &&
>>         cat bin.png bin.png > bin.png &&
>>         git add bin.png &&
>>         git commit -m "update binary file" &&
>>
>>         # 3. make patch
>>         git diff --binary left..right >bin.diff &&
>>         # apply --3way, and it will fail
>>         test_must_fail git apply --index --3way bin.diff
>> '
>> "
>>
>> But  "git apply --index --3way bin.diff" will not faill on Git version 2.31.0.
> Are you sure? I checked out to "commit
> a5828ae6b52137b913b978e16cd2334482eb4c1f (HEAD, tag: v2.31.0)" and
> rebuilt and ran your test snippet and it still failed.

Isn't it just because the reproduction recipe is simply wrong?

It says

    * be on left branch and have a binary file
    * be on right branch and have a modified binary file
    * create a patch to take left to right

Notice that we have a patch and we are still on the right branch.
Of course, applying the patch to take us from left to right would
fail from that state, but I _think_ the intent of the reproduction
recipe was, after all of the above, do this here:

    * switch to left branch and attempt to apply the patch.

And the patch is meant to take us from left to right, and we are on
pristine left, the application ought to cleanly succeed, no?

"git apply bin.diff" would probably work correctly but I do not know
offhand what the code after your change does with --3way enabled.

We refuse to merge binary files, so I would not be surprised if we
failed the 3way in this case (even though we _could_ fast-forward,
it may not be worth complicating the --3way logic---nobody sane
would say --3way when it is unnecessary) but after 3way fails, do we
still correctly fall back to "straight application" like we do for
text patches with your change?  Before your change, we would have
first attempted the "straight application", which would succeed and
wouldn't have hit "3way will refuse to merge binaries" at all.

So, I do not think it is implausible that we are seeing a legit
regression report.

Thanks.

Re: git apply --3way behaves abnormally when the patch contains binary changes.

[Jerry Zhang]

On Tue, Jul 27, 2021 at 6:08 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Jerry Zhang <jerry@skydio.com> writes:
>
> >>         # 2. based on left_bin branch, make any change, and commit
> >>         git checkout -b right &&
> >>         cat bin.png bin.png > bin.png &&
> >>         git add bin.png &&
> >>         git commit -m "update binary file" &&
> >>
> >>         # 3. make patch
> >>         git diff --binary left..right >bin.diff &&
> >>         # apply --3way, and it will fail
> >>         test_must_fail git apply --index --3way bin.diff
> >> '
> >> "
> >>
> >> But  "git apply --index --3way bin.diff" will not faill on Git version 2.31.0.
> > Are you sure? I checked out to "commit
> > a5828ae6b52137b913b978e16cd2334482eb4c1f (HEAD, tag: v2.31.0)" and
> > rebuilt and ran your test snippet and it still failed.
>
> Isn't it just because the reproduction recipe is simply wrong?
>
> It says
>
>     * be on left branch and have a binary file
>     * be on right branch and have a modified binary file
>     * create a patch to take left to right
>
> Notice that we have a patch and we are still on the right branch.
> Of course, applying the patch to take us from left to right would
> fail from that state, but I _think_ the intent of the reproduction
> recipe was, after all of the above, do this here:
>
>     * switch to left branch and attempt to apply the patch.
>
> And the patch is meant to take us from left to right, and we are on
> pristine left, the application ought to cleanly succeed, no?
>
> "git apply bin.diff" would probably work correctly but I do not know
> offhand what the code after your change does with --3way enabled.
>
> We refuse to merge binary files, so I would not be surprised if we
> failed the 3way in this case (even though we _could_ fast-forward,
> it may not be worth complicating the --3way logic---nobody sane
> would say --3way when it is unnecessary) but after 3way fails, do we
> still correctly fall back to "straight application" like we do for
> text patches with your change?  Before your change, we would have
> first attempted the "straight application", which would succeed and
> wouldn't have hit "3way will refuse to merge binaries" at all.
Ah yep it's exactly as you say. I'll add the fix and a couple of test cases
into a new patch.
>
> So, I do not think it is implausible that we are seeing a legit
> regression report.
>
> Thanks.

Re: Re: git apply --3way behaves abnormally when the patch contains binary changes.

[lilinchao]

The defective test demo I provided is not that important(for me), the purpose of this is to
bring out our topic that "git apply -3" behaves differently on different Git version when
the patch is binary.
Maybe I would say this breaks backward compatibility, but the poor test demo didn't prove this. 
If anyone would like to see the incompatibility, he can run "git apply --index  -3 binary.diff" in command line in different Git version environment.

>Jerry Zhang <jerry@skydio.com> writes:
>
>>>         # 2. based on left_bin branch, make any change, and commit
>>>         git checkout -b right &&
>>>         cat bin.png bin.png > bin.png &&
>>>         git add bin.png &&
>>>         git commit -m "update binary file" &&
>>>
>>>         # 3. make patch
>>>         git diff --binary left..right >bin.diff &&
>>>         # apply --3way, and it will fail
>>>         test_must_fail git apply --index --3way bin.diff
>>> '
>>> "
>>>
>>> But  "git apply --index --3way bin.diff" will not faill on Git version 2.31.0.
>> Are you sure? I checked out to "commit
>> a5828ae6b52137b913b978e16cd2334482eb4c1f (HEAD, tag: v2.31.0)" and
>> rebuilt and ran your test snippet and it still failed.
>
>Isn't it just because the reproduction recipe is simply wrong?
>
>It says
>
>    * be on left branch and have a binary file
>    * be on right branch and have a modified binary file
>    * create a patch to take left to right
>
>Notice that we have a patch and we are still on the right branch.
>Of course, applying the patch to take us from left to right would
>fail from that state, but I _think_ the intent of the reproduction
>recipe was, after all of the above, do this here:
>
>    * switch to left branch and attempt to apply the patch.
>
>And the patch is meant to take us from left to right, and we are on
>pristine left, the application ought to cleanly succeed, no?
>
>"git apply bin.diff" would probably work correctly but I do not know
>offhand what the code after your change does with --3way enabled.
>
>We refuse to merge binary files, so I would not be surprised if we
>failed the 3way in this case (even though we _could_ fast-forward,
>it may not be worth complicating the --3way logic---nobody sane
>would say --3way when it is unnecessary) but after 3way fails, do we
>still correctly fall back to "straight application" like we do for
>text patches with your change?  Before your change, we would have
>first attempted the "straight application", which would succeed and
>wouldn't have hit "3way will refuse to merge binaries" at all.
>
>So, I do not think it is implausible that we are seeing a legit
>regression report.
>
>Thanks.