diff options
author | Junio C Hamano <gitster@pobox.com> | 2021-09-05 12:06:57 -0700 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2021-09-05 15:39:02 -0700 |
commit | 57f183b698ca4f967266577687f09b09a79f0b8c (patch) | |
tree | 01de1fead89dedad212fa797daad33adea19eadc /Documentation/git-rebase.txt | |
parent | The sixth batch (diff) | |
download | tgif-57f183b698ca4f967266577687f09b09a79f0b8c.tar.xz |
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>
Diffstat (limited to 'Documentation/git-rebase.txt')
0 files changed, 0 insertions, 0 deletions