summaryrefslogtreecommitdiff
path: root/merge-recursive.c
diff options
context:
space:
mode:
authorElijah Newren <newren@gmail.com>2011-08-11 23:20:18 -0600
committerJunio C Hamano <gitster@pobox.com>2011-08-14 14:19:39 -0700
commit434b8525e7a68893106f6360ff0a261f03c37512 (patch)
treea618e0629b7224b8336ed9e9b2d9ae8d16e76659 /merge-recursive.c
parentdac4741554e7672e69d1bc6b4f912cd16ad83b38 (diff)
downloadgit-434b8525e7a68893106f6360ff0a261f03c37512.tar.gz
merge-recursive: Consider modifications in rename/rename(2to1) conflicts
Our previous conflict resolution for renaming two different files to the same name ignored the fact that each of those files may have modifications from both sides of history to consider. We need to do a three-way merge for each of those files, and then handle the conflict of both sets of merged contents trying to be recorded with the same name. It is important to note that this changes our strategy in the recursive case. After doing a three-way content merge of each of the files involved, we still are faced with the fact that we are trying to put both of the results (including conflict markers) into the same path. We could do another two-way merge, but I think that becomes confusing. Also, taking a hint from the modify/delete and rename/delete cases we handled earlier, a more useful "common ground" would be to keep the three-way content merge but record it with the original filename. The renames can still be detected, we just allow it to be done in the o->call_depth=0 case. This seems to result in simpler & easier to understand merge conflicts as well, as evidenced by some of the changes needed in our testsuite in t6036. (However, it should be noted that this change will cause problems those renames also occur along with a file being added whose name matches the source of the rename. Since git currently cannot detect rename/add-source situations, though, this codepath is not currently used for those cases anyway. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'merge-recursive.c')
-rw-r--r--merge-recursive.c30
1 files changed, 21 insertions, 9 deletions
diff --git a/merge-recursive.c b/merge-recursive.c
index 4ceb6aac88..3124144011 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1081,6 +1081,8 @@ static void conflict_rename_rename_2to1(struct merge_options *o,
struct diff_filespec *c1 = ci->pair1->two;
struct diff_filespec *c2 = ci->pair2->two;
char *path = c1->path; /* == c2->path */
+ struct merge_file_info mfi_c1;
+ struct merge_file_info mfi_c2;
output(o, 1, "CONFLICT (rename/rename): "
"Rename %s->%s in %s. "
@@ -1091,22 +1093,32 @@ static void conflict_rename_rename_2to1(struct merge_options *o,
remove_file(o, 1, a->path, would_lose_untracked(a->path));
remove_file(o, 1, b->path, would_lose_untracked(b->path));
+ mfi_c1 = merge_file_special_markers(o, a, c1, &ci->ren1_other,
+ o->branch1, c1->path,
+ o->branch2, ci->ren1_other.path);
+ mfi_c2 = merge_file_special_markers(o, b, &ci->ren2_other, c2,
+ o->branch1, ci->ren2_other.path,
+ o->branch2, c2->path);
+
if (o->call_depth) {
- struct merge_file_info mfi;
- mfi = merge_file(o, path, null_sha1, 0,
- c1->sha1, c1->mode,
- c2->sha1, c2->mode,
- ci->branch1, ci->branch2);
- output(o, 1, "Adding merged %s", path);
- update_file(o, 0, mfi.sha, mfi.mode, path);
+ /*
+ * If mfi_c1.clean && mfi_c2.clean, then it might make
+ * sense to do a two-way merge of those results. But, I
+ * think in all cases, it makes sense to have the virtual
+ * merge base just undo the renames; they can be detected
+ * again later for the non-recursive merge.
+ */
+ remove_file(o, 0, path, 0);
+ update_file(o, 0, mfi_c1.sha, mfi_c1.mode, a->path);
+ update_file(o, 0, mfi_c2.sha, mfi_c2.mode, b->path);
} else {
char *new_path1 = unique_path(o, path, ci->branch1);
char *new_path2 = unique_path(o, path, ci->branch2);
output(o, 1, "Renaming %s to %s and %s to %s instead",
a->path, new_path1, b->path, new_path2);
remove_file(o, 0, path, 0);
- update_file(o, 0, c1->sha1, c1->mode, new_path1);
- update_file(o, 0, c2->sha1, c2->mode, new_path2);
+ update_file(o, 0, mfi_c1.sha, mfi_c1.mode, new_path1);
+ update_file(o, 0, mfi_c2.sha, mfi_c2.mode, new_path2);
free(new_path2);
free(new_path1);
}