Jeff King <peff@xxxxxxxx> writes: > 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. Makes sense. > 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. Nice discovery. Thanks.
