merge-recursive: fix rename/rename(1to2) for working tree with a binary

From: Elijah Newren <[email protected]>

With a rename/rename(1to2) conflict, we attempt to do a three-way merge of the file contents, so that the correct contents can be placed in the working tree at both paths. If the file is a binary, however, no content merging is possible and we should just use the original version of the file at each of the paths.

---
merge-recursive: fix rename/rename(1to2) for working tree with a binary

rename/rename(1to2) is unique among our conflict resolutions in that it tries to put the as-merged-as-possible contents into two different paths, so I think this should be the only code path that needs an update for this issue.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-784%2Fnewren%2Frr1to2-binary-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-784/newren/rr1to2-binary-v1
Pull-Request: https://github.com/git/git/pull/784

 merge-recursive.c                    | 12 ++++++
 t/t6042-merge-rename-corner-cases.sh | 55 ++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+)

index d92e2acf1ed..36948eafb75 100644
@@ -1750,6 +1750,18 @@ static int handle_rename_rename_1to2(struct merge_options *opt,
 			return -1;
 	}
 
+	if (!mfi.clean && mfi.blob.mode == a->mode &&
+	    oideq(&mfi.blob.oid, &a->oid)) {
+		/*
+		 * Getting here means we were attempting to merge a binary
+		 * blob.  Since we can't merge binaries, the merge algorithm
+		 * just takes one side.  But we don't want to copy the
+		 * contents of one side to both paths; we'd rather use the
+		 * original content at the given path for each path.
+		 */
+		oidcpy(&mfi.blob.oid, &b->oid);
+		mfi.blob.mode = b->mode;
+	}
 	add = &ci->ren2->dst_entry->stages[flip_stage(3)];
 	if (is_valid(add)) {
 		add->path = mfi.blob.path = b->path;

base-commit: b994622632154fc3b17fb40a38819ad954a5fb88

gitgitgadget