apply: resolve trivial merge without hitting ll-merge with "--3way"
commit57f183b698ca4f967266577687f09b09a79f0b8c
authorJunio C Hamano <gitster@pobox.com>
Sun, 5 Sep 2021 19:06:57 +0000 (5 12:06 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sun, 5 Sep 2021 22:39:02 +0000 (5 15:39 -0700)
tree01de1fead89dedad212fa797daad33adea19eadc
parenteb27b338a3e71c7c4079fbac8aeae3f8fbb5c687
apply: resolve trivial merge without hitting ll-merge with "--3way"

The ll_binary_merge() function assumes that the ancestor blob is
different from either side of the new versions, and always fails
the merge in conflict, unless -Xours or -Xtheirs is in effect.

The normal "merge" machineries all resolve the trivial cases
(e.g. if our side changed while their side did not, the result
is ours) without triggering the file-level merge drivers, so the
assumption is warranted.

The code path in "git apply --3way", however, does not check for
the trivial three-way merge situation and always calls the
file-level merge drivers.  This used to be perfectly OK back
when we always first attempted a straight patch application and
used the three-way code path only as a fallback.  Any binary
patch that can be applied as a trivial three-way merge (e.g. the
patch is based exactly on the version we happen to have) would
always cleanly apply, so the ll_binary_merge() that is not
prepared to see the trivial case would not have to handle such a
case.

This no longer is true after we made "--3way" to mean "first try
three-way and then fall back to straight application", and made
"git apply -3" on a binary patch that is based on the current
version no longer apply.

Teach "git apply -3" to first check for the trivial merge cases
and resolve them without hitting the file-level merge drivers.

Signed-off-by: Jerry Zhang <jerry@skydio.com>
[jc: stolen tests from Jerry's patch]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply.c
t/t4108-apply-threeway.sh