diff options
author | Jeff King <peff@peff.net> | 2021-06-10 08:57:05 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2021-06-11 12:37:04 +0900 |
commit | 7d879ad7e02f1f4d7f504862b280e503db403a36 (patch) | |
tree | 7b3cccd371edb865dd9f75b39074e7fc411d608e /t/t1013-read-tree-submodule.sh | |
parent | Git 2.31.1 (diff) | |
download | tgif-7d879ad7e02f1f4d7f504862b280e503db403a36.tar.xz |
ll_binary_merge(): handle XDL_MERGE_FAVOR_UNION
Prior to commit a944af1d86 (merge: teach -Xours/-Xtheirs to binary
ll-merge driver, 2012-09-08), we always reported a conflict from
ll_binary_merge() by returning "1" (in the xdl_merge and ll_merge code,
this value is the number of conflict hunks). After that commit, we
report zero conflicts if the "variant" flag is set, under the assumption
that it is one of XDL_MERGE_FAVOR_OURS or XDL_MERGE_FAVOR_THEIRS.
But this gets confused by XDL_MERGE_FAVOR_UNION. We do not know how to
do a binary union merge, but erroneously report no conflicts anyway (and
just blindly use the "ours" content as the result).
Let's tighten our check to just the cases that a944af1d86 meant to
cover. This fixes the union case (which existed already back when that
commit was made), as well as future-proofing us against any other
variants that get added later.
Note that you can't trigger this from "git merge-file --union", as that
bails on binary files before even calling into the ll-merge machinery.
The test here uses the "union" merge attribute, which does erroneously
report a successful merge.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t1013-read-tree-submodule.sh')
0 files changed, 0 insertions, 0 deletions