From 864075ec433644e5908589fe79f8b3296f896867 Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Mon, 14 Dec 2020 16:21:30 +0000 Subject: [PATCH 01/11] merge-ort: add basic data structures for handling renames This will grow later, but we only need a few fields for basic rename handling. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/merge-ort.c b/merge-ort.c index 414e7b7eea..1c1a7fa4bf 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -46,6 +46,25 @@ enum merge_side { MERGE_SIDE2 = 2 }; +struct rename_info { + /* + * pairs: pairing of filenames from diffcore_rename() + * + * Index 1 and 2 correspond to sides 1 & 2 as used in + * conflict_info.stages. Index 0 unused. + */ + struct diff_queue_struct pairs[3]; + + /* + * needed_limit: value needed for inexact rename detection to run + * + * If the current rename limit wasn't high enough for inexact + * rename detection to run, this records the limit needed. Otherwise, + * this value remains 0. + */ + int needed_limit; +}; + struct merge_options_internal { /* * paths: primary data structure in all of merge ort. @@ -113,6 +132,11 @@ struct merge_options_internal { */ struct strmap output; + /* + * renames: various data relating to rename detection + */ + struct rename_info renames; + /* * current_dir_name: temporary var used in collect_merge_info_callback() * From e1a124e8dc3d21afedc80cc2842d705c1d5a90c9 Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Mon, 14 Dec 2020 16:21:31 +0000 Subject: [PATCH 02/11] merge-ort: add initial outline for basic rename detection Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 60 insertions(+), 8 deletions(-) diff --git a/merge-ort.c b/merge-ort.c index 1c1a7fa4bf..8552f5e231 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -644,20 +644,72 @@ static int handle_content_merge(struct merge_options *opt, /*** Function Grouping: functions related to regular rename detection ***/ +static int process_renames(struct merge_options *opt, + struct diff_queue_struct *renames) +{ + die("Not yet implemented."); +} + +static int compare_pairs(const void *a_, const void *b_) +{ + die("Not yet implemented."); +} + +/* Call diffcore_rename() to compute which files have changed on given side */ +static void detect_regular_renames(struct merge_options *opt, + struct tree *merge_base, + struct tree *side, + unsigned side_index) +{ + die("Not yet implemented."); +} + +/* + * Get information of all renames which occurred in 'side_pairs', discarding + * non-renames. + */ +static int collect_renames(struct merge_options *opt, + struct diff_queue_struct *result, + unsigned side_index) +{ + die("Not yet implemented."); +} + static int detect_and_process_renames(struct merge_options *opt, struct tree *merge_base, struct tree *side1, struct tree *side2) { - int clean = 1; + struct diff_queue_struct combined; + struct rename_info *renames = &opt->priv->renames; + int s, clean = 1; + + memset(&combined, 0, sizeof(combined)); + + detect_regular_renames(opt, merge_base, side1, MERGE_SIDE1); + detect_regular_renames(opt, merge_base, side2, MERGE_SIDE2); + + ALLOC_GROW(combined.queue, + renames->pairs[1].nr + renames->pairs[2].nr, + combined.alloc); + clean &= collect_renames(opt, &combined, MERGE_SIDE1); + clean &= collect_renames(opt, &combined, MERGE_SIDE2); + QSORT(combined.queue, combined.nr, compare_pairs); + + clean &= process_renames(opt, &combined); + + /* Free memory for renames->pairs[] and combined */ + for (s = MERGE_SIDE1; s <= MERGE_SIDE2; s++) { + free(renames->pairs[s].queue); + DIFF_QUEUE_CLEAR(&renames->pairs[s]); + } + if (combined.nr) { + int i; + for (i = 0; i < combined.nr; i++) + diff_free_filepair(combined.queue[i]); + free(combined.queue); + } - /* - * Rename detection works by detecting file similarity. Here we use - * a really easy-to-implement scheme: files are similar IFF they have - * the same filename. Therefore, by this scheme, there are no renames. - * - * TODO: Actually implement a real rename detection scheme. - */ return clean; } From f39d05ca2637dfcbf0498824d06e7854427936a5 Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Mon, 14 Dec 2020 16:21:32 +0000 Subject: [PATCH 03/11] merge-ort: implement detect_regular_renames() Based heavily on merge-recursive's get_diffpairs() function, and also includes the necessary paired call to diff_warn_rename_limit() so that users will be warned if merge.renameLimit is not sufficiently large for rename detection to run. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/merge-ort.c b/merge-ort.c index 8552f5e231..66f84d39b4 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -661,7 +661,33 @@ static void detect_regular_renames(struct merge_options *opt, struct tree *side, unsigned side_index) { - die("Not yet implemented."); + struct diff_options diff_opts; + struct rename_info *renames = &opt->priv->renames; + + repo_diff_setup(opt->repo, &diff_opts); + diff_opts.flags.recursive = 1; + diff_opts.flags.rename_empty = 0; + diff_opts.detect_rename = DIFF_DETECT_RENAME; + diff_opts.rename_limit = opt->rename_limit; + if (opt->rename_limit <= 0) + diff_opts.rename_limit = 1000; + diff_opts.rename_score = opt->rename_score; + diff_opts.show_rename_progress = opt->show_rename_progress; + diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT; + diff_setup_done(&diff_opts); + diff_tree_oid(&merge_base->object.oid, &side->object.oid, "", + &diff_opts); + diffcore_std(&diff_opts); + + if (diff_opts.needed_rename_limit > renames->needed_limit) + renames->needed_limit = diff_opts.needed_rename_limit; + + renames->pairs[side_index] = diff_queued_diff; + + diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT; + diff_queued_diff.nr = 0; + diff_queued_diff.queue = NULL; + diff_flush(&diff_opts); } /* @@ -1406,6 +1432,10 @@ void merge_switch_to_result(struct merge_options *opt, printf("%s", sb->buf); } string_list_clear(&olist, 0); + + /* Also include needed rename limit adjustment now */ + diff_warn_rename_limit("merge.renamelimit", + opti->renames.needed_limit, 0); } merge_finalize(opt, result); From 965a7bc21c6bb11fb15eb798fd472ec9deb5e3fa Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Mon, 14 Dec 2020 16:21:33 +0000 Subject: [PATCH 04/11] merge-ort: implement compare_pairs() and collect_renames() Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 35 +++++++++++++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/merge-ort.c b/merge-ort.c index 66f84d39b4..10550c542b 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -652,7 +652,10 @@ static int process_renames(struct merge_options *opt, static int compare_pairs(const void *a_, const void *b_) { - die("Not yet implemented."); + const struct diff_filepair *a = *((const struct diff_filepair **)a_); + const struct diff_filepair *b = *((const struct diff_filepair **)b_); + + return strcmp(a->one->path, b->one->path); } /* Call diffcore_rename() to compute which files have changed on given side */ @@ -698,7 +701,35 @@ static int collect_renames(struct merge_options *opt, struct diff_queue_struct *result, unsigned side_index) { - die("Not yet implemented."); + int i, clean = 1; + struct diff_queue_struct *side_pairs; + struct rename_info *renames = &opt->priv->renames; + + side_pairs = &renames->pairs[side_index]; + + for (i = 0; i < side_pairs->nr; ++i) { + struct diff_filepair *p = side_pairs->queue[i]; + + if (p->status != 'R') { + diff_free_filepair(p); + continue; + } + + /* + * p->score comes back from diffcore_rename_extended() with + * the similarity of the renamed file. The similarity is + * was used to determine that the two files were related + * and are a rename, which we have already used, but beyond + * that we have no use for the similarity. So p->score is + * now irrelevant. However, process_renames() will need to + * know which side of the merge this rename was associated + * with, so overwrite p->score with that value. + */ + p->score = side_index; + result->queue[result->nr++] = p; + } + + return clean; } static int detect_and_process_renames(struct merge_options *opt, From c2d267df0215d49f06638463889465389134021a Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Mon, 14 Dec 2020 16:21:34 +0000 Subject: [PATCH 05/11] merge-ort: add basic outline for process_renames() Add code which determines which kind of special rename case each rename corresponds to, but leave the handling of each type unimplemented for now. Future commits will implement each one. There is some tenuous resemblance to merge-recursive's process_renames(), but comparing the two is very unlikely to yield any insights. merge-ort's process_renames() is a bit complex and I would prefer if I could simplify it more, but it is far easier to grok than merge-recursive's function of the same name in my opinion. Plus, merge-ort handles more rename conflict types than merge-recursive does. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 97 insertions(+), 1 deletion(-) diff --git a/merge-ort.c b/merge-ort.c index 10550c542b..ebe275ef73 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -647,7 +647,103 @@ static int handle_content_merge(struct merge_options *opt, static int process_renames(struct merge_options *opt, struct diff_queue_struct *renames) { - die("Not yet implemented."); + int clean_merge = 1, i; + + for (i = 0; i < renames->nr; ++i) { + const char *oldpath = NULL, *newpath; + struct diff_filepair *pair = renames->queue[i]; + struct conflict_info *oldinfo = NULL, *newinfo = NULL; + struct strmap_entry *old_ent, *new_ent; + unsigned int old_sidemask; + int target_index, other_source_index; + int source_deleted, collision, type_changed; + + old_ent = strmap_get_entry(&opt->priv->paths, pair->one->path); + oldpath = old_ent->key; + oldinfo = old_ent->value; + + new_ent = strmap_get_entry(&opt->priv->paths, pair->two->path); + newpath = new_ent->key; + newinfo = new_ent->value; + + /* + * diff_filepairs have copies of pathnames, thus we have to + * use standard 'strcmp()' (negated) instead of '=='. + */ + if (i + 1 < renames->nr && + !strcmp(oldpath, renames->queue[i+1]->one->path)) { + /* Handle rename/rename(1to2) or rename/rename(1to1) */ + const char *pathnames[3]; + + pathnames[0] = oldpath; + pathnames[1] = newpath; + pathnames[2] = renames->queue[i+1]->two->path; + + if (!strcmp(pathnames[1], pathnames[2])) { + /* Both sides renamed the same way. */ + die("Not yet implemented"); + + /* We handled both renames, i.e. i+1 handled */ + i++; + /* Move to next rename */ + continue; + } + + /* This is a rename/rename(1to2) */ + die("Not yet implemented"); + + i++; /* We handled both renames, i.e. i+1 handled */ + continue; + } + + VERIFY_CI(oldinfo); + VERIFY_CI(newinfo); + target_index = pair->score; /* from collect_renames() */ + assert(target_index == 1 || target_index == 2); + other_source_index = 3 - target_index; + old_sidemask = (1 << other_source_index); /* 2 or 4 */ + source_deleted = (oldinfo->filemask == 1); + collision = ((newinfo->filemask & old_sidemask) != 0); + type_changed = !source_deleted && + (S_ISREG(oldinfo->stages[other_source_index].mode) != + S_ISREG(newinfo->stages[target_index].mode)); + if (type_changed && collision) { + /* special handling so later blocks can handle this */ + die("Not yet implemented"); + } + + assert(source_deleted || oldinfo->filemask & old_sidemask); + + /* Need to check for special types of rename conflicts... */ + if (collision && !source_deleted) { + /* collision: rename/add or rename/rename(2to1) */ + die("Not yet implemented"); + } else if (collision && source_deleted) { + /* rename/add/delete or rename/rename(2to1)/delete */ + die("Not yet implemented"); + } else { + /* a few different cases... */ + if (type_changed) { + /* rename vs. typechange */ + die("Not yet implemented"); + } else if (source_deleted) { + /* rename/delete */ + die("Not yet implemented"); + } else { + /* normal rename */ + die("Not yet implemented"); + } + } + + if (!type_changed) { + /* Mark the original as resolved by removal */ + oldinfo->merged.is_null = 1; + oldinfo->merged.clean = 1; + } + + } + + return clean_merge; } static int compare_pairs(const void *a_, const void *b_) From af1e56c49e61a39d5a7d78cecb97f350b5a3834a Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Tue, 15 Dec 2020 18:28:01 +0000 Subject: [PATCH 06/11] merge-ort: add implementation of both sides renaming identically Implement rename/rename(1to1) handling, i.e. both sides of history renaming a file but renaming the same way. This code replaces the following from merge-recurisve.c: * all the 1to1 code in process_renames() * the RENAME_ONE_FILE_TO_ONE case of process_entry() Also, there is some shared code from merge-recursive.c for multiple different rename cases which we will no longer need for this case (or other rename cases): * handle_rename_normal() * setup_rename_conflict_info() The consolidation of four separate codepaths into one is made possible by a change in design: process_renames() tweaks the conflict_info entries within opt->priv->paths such that process_entry() can then handle all the non-rename conflict types (directory/file, modify/delete, etc.) orthogonally. This means we're much less likely to miss special implementation of some kind of combination of conflict types (see commits brought in by 66c62eaec6 ("Merge branch 'en/merge-tests'", 2020-11-18), especially commit ef52778708 ("merge tests: expect improved directory/file conflict handling in ort", 2020-10-26) for more details). That, together with letting worktree/index updating be handled orthogonally in the merge_switch_to_result() function, dramatically simplifies the code for various special rename cases. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/merge-ort.c b/merge-ort.c index ebe275ef73..da3715baa6 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -674,14 +674,30 @@ static int process_renames(struct merge_options *opt, !strcmp(oldpath, renames->queue[i+1]->one->path)) { /* Handle rename/rename(1to2) or rename/rename(1to1) */ const char *pathnames[3]; + struct version_info merged; + struct conflict_info *base, *side1, *side2; pathnames[0] = oldpath; pathnames[1] = newpath; pathnames[2] = renames->queue[i+1]->two->path; + base = strmap_get(&opt->priv->paths, pathnames[0]); + side1 = strmap_get(&opt->priv->paths, pathnames[1]); + side2 = strmap_get(&opt->priv->paths, pathnames[2]); + + VERIFY_CI(base); + VERIFY_CI(side1); + VERIFY_CI(side2); + if (!strcmp(pathnames[1], pathnames[2])) { - /* Both sides renamed the same way. */ - die("Not yet implemented"); + /* Both sides renamed the same way */ + assert(side1 == side2); + memcpy(&side1->stages[0], &base->stages[0], + sizeof(merged)); + side1->filemask |= (1 << MERGE_BASE); + /* Mark base as resolved by removal */ + base->merged.is_null = 1; + base->merged.clean = 1; /* We handled both renames, i.e. i+1 handled */ i++; From 53e88a03539db70a7e990489784400b0b2916fa9 Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Tue, 15 Dec 2020 18:28:02 +0000 Subject: [PATCH 07/11] merge-ort: add implementation of both sides renaming differently Implement rename/rename(1to2) handling, i.e. both sides of history renaming a file and rename it differently. This code replaces the following from merge-recurisve.c: * all the 1to2 code in process_renames() * the RENAME_ONE_FILE_TO_TWO case of process_entry() * handle_rename_rename_1to2() Also, there is some shared code from merge-recursive.c for multiple different rename cases which we will no longer need for this case (or other rename cases): * handle_file_collision() * setup_rename_conflict_info() The consolidation of five separate codepaths into one is made possible by a change in design: process_renames() tweaks the conflict_info entries within opt->priv->paths such that process_entry() can then handle all the non-rename conflict types (directory/file, modify/delete, etc.) orthogonally. This means we're much less likely to miss special implementation of some kind of combination of conflict types (see commits brought in by 66c62eaec6 ("Merge branch 'en/merge-tests'", 2020-11-18), especially commit ef52778708 ("merge tests: expect improved directory/file conflict handling in ort", 2020-10-26) for more details). That, together with letting worktree/index updating be handled orthogonally in the merge_switch_to_result() function, dramatically simplifies the code for various special rename cases. To be fair, there is a _slight_ tweak to process_entry() here to make sure that the two different paths aren't marked as clean but are left in a conflicted state. So process_renames() and process_entry() aren't quite entirely orthogonal, but they are pretty close. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 55 insertions(+), 3 deletions(-) diff --git a/merge-ort.c b/merge-ort.c index da3715baa6..19477cfae6 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -676,6 +676,7 @@ static int process_renames(struct merge_options *opt, const char *pathnames[3]; struct version_info merged; struct conflict_info *base, *side1, *side2; + unsigned was_binary_blob = 0; pathnames[0] = oldpath; pathnames[1] = newpath; @@ -706,7 +707,58 @@ static int process_renames(struct merge_options *opt, } /* This is a rename/rename(1to2) */ - die("Not yet implemented"); + clean_merge = handle_content_merge(opt, + pair->one->path, + &base->stages[0], + &side1->stages[1], + &side2->stages[2], + pathnames, + 1 + 2 * opt->priv->call_depth, + &merged); + if (!clean_merge && + merged.mode == side1->stages[1].mode && + oideq(&merged.oid, &side1->stages[1].oid)) + was_binary_blob = 1; + memcpy(&side1->stages[1], &merged, sizeof(merged)); + if (was_binary_blob) { + /* + * Getting here means we were attempting to + * merge a binary blob. + * + * Since we can't merge binaries, + * handle_content_merge() just takes one + * side. But we don't want to copy the + * contents of one side to both paths. We + * used the contents of side1 above for + * side1->stages, let's use the contents of + * side2 for side2->stages below. + */ + oidcpy(&merged.oid, &side2->stages[2].oid); + merged.mode = side2->stages[2].mode; + } + memcpy(&side2->stages[2], &merged, sizeof(merged)); + + side1->path_conflict = 1; + side2->path_conflict = 1; + /* + * TODO: For renames we normally remove the path at the + * old name. It would thus seem consistent to do the + * same for rename/rename(1to2) cases, but we haven't + * done so traditionally and a number of the regression + * tests now encode an expectation that the file is + * left there at stage 1. If we ever decide to change + * this, add the following two lines here: + * base->merged.is_null = 1; + * base->merged.clean = 1; + * and remove the setting of base->path_conflict to 1. + */ + base->path_conflict = 1; + path_msg(opt, oldpath, 0, + _("CONFLICT (rename/rename): %s renamed to " + "%s in %s and to %s in %s."), + pathnames[0], + pathnames[1], opt->branch1, + pathnames[2], opt->branch2); i++; /* We handled both renames, i.e. i+1 handled */ continue; @@ -1291,13 +1343,13 @@ static void process_entry(struct merge_options *opt, int side = (ci->filemask == 4) ? 2 : 1; ci->merged.result.mode = ci->stages[side].mode; oidcpy(&ci->merged.result.oid, &ci->stages[side].oid); - ci->merged.clean = !ci->df_conflict; + ci->merged.clean = !ci->df_conflict && !ci->path_conflict; } else if (ci->filemask == 1) { /* Deleted on both sides */ ci->merged.is_null = 1; ci->merged.result.mode = 0; oidcpy(&ci->merged.result.oid, &null_oid); - ci->merged.clean = 1; + ci->merged.clean = !ci->path_conflict; } /* From 2e91ddd24e7240460fd2a9aee1962345ed858b6b Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Tue, 15 Dec 2020 18:28:03 +0000 Subject: [PATCH 08/11] merge-ort: add implementation of rename/delete conflicts Implement rename/delete conflicts, i.e. one side renames a file and the other deletes the file. This code replaces the following from merge-recurisve.c: * the code relevant to RENAME_DELETE in process_renames() * the RENAME_DELETE case of process_entry() * handle_rename_delete() Also, there is some shared code from merge-recursive.c for multiple different rename cases which we will no longer need for this case (or other rename cases): * handle_change_delete() * setup_rename_conflict_info() The consolidation of five separate codepaths into one is made possible by a change in design: process_renames() tweaks the conflict_info entries within opt->priv->paths such that process_entry() can then handle all the non-rename conflict types (directory/file, modify/delete, etc.) orthogonally. This means we're much less likely to miss special implementation of some kind of combination of conflict types (see commits brought in by 66c62eaec6 ("Merge branch 'en/merge-tests'", 2020-11-18), especially commit ef52778708 ("merge tests: expect improved directory/file conflict handling in ort", 2020-10-26) for more details). That, together with letting worktree/index updating be handled orthogonally in the merge_switch_to_result() function, dramatically simplifies the code for various special rename cases. To be fair, there is a _slight_ tweak to process_entry() here, because rename/delete cases will also trigger the modify/delete codepath. However, we only want a modify/delete message to be printed for a rename/delete conflict if there is a content change in the renamed file in addition to the rename. So process_renames() and process_entry() aren't quite fully orthogonal, but they are pretty close. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 48 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 40 insertions(+), 8 deletions(-) diff --git a/merge-ort.c b/merge-ort.c index 19477cfae6..a10c3f5046 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -657,6 +657,7 @@ static int process_renames(struct merge_options *opt, unsigned int old_sidemask; int target_index, other_source_index; int source_deleted, collision, type_changed; + const char *rename_branch = NULL, *delete_branch = NULL; old_ent = strmap_get_entry(&opt->priv->paths, pair->one->path); oldpath = old_ent->key; @@ -779,6 +780,15 @@ static int process_renames(struct merge_options *opt, /* special handling so later blocks can handle this */ die("Not yet implemented"); } + if (source_deleted) { + if (target_index == 1) { + rename_branch = opt->branch1; + delete_branch = opt->branch2; + } else { + rename_branch = opt->branch2; + delete_branch = opt->branch1; + } + } assert(source_deleted || oldinfo->filemask & old_sidemask); @@ -790,13 +800,26 @@ static int process_renames(struct merge_options *opt, /* rename/add/delete or rename/rename(2to1)/delete */ die("Not yet implemented"); } else { - /* a few different cases... */ + /* + * a few different cases...start by copying the + * existing stage(s) from oldinfo over the newinfo + * and update the pathname(s). + */ + memcpy(&newinfo->stages[0], &oldinfo->stages[0], + sizeof(newinfo->stages[0])); + newinfo->filemask |= (1 << MERGE_BASE); + newinfo->pathnames[0] = oldpath; if (type_changed) { /* rename vs. typechange */ die("Not yet implemented"); } else if (source_deleted) { /* rename/delete */ - die("Not yet implemented"); + newinfo->path_conflict = 1; + path_msg(opt, newpath, 0, + _("CONFLICT (rename/delete): %s renamed" + " to %s in %s, but deleted in %s."), + oldpath, newpath, + rename_branch, delete_branch); } else { /* normal rename */ die("Not yet implemented"); @@ -1332,12 +1355,21 @@ static void process_entry(struct merge_options *opt, modify_branch = (side == 1) ? opt->branch1 : opt->branch2; delete_branch = (side == 1) ? opt->branch2 : opt->branch1; - path_msg(opt, path, 0, - _("CONFLICT (modify/delete): %s deleted in %s " - "and modified in %s. Version %s of %s left " - "in tree."), - path, delete_branch, modify_branch, - modify_branch, path); + if (ci->path_conflict && + oideq(&ci->stages[0].oid, &ci->stages[side].oid)) { + /* + * This came from a rename/delete; no action to take, + * but avoid printing "modify/delete" conflict notice + * since the contents were not modified. + */ + } else { + path_msg(opt, path, 0, + _("CONFLICT (modify/delete): %s deleted in %s " + "and modified in %s. Version %s of %s left " + "in tree."), + path, delete_branch, modify_branch, + modify_branch, path); + } } else if (ci->filemask == 2 || ci->filemask == 4) { /* Added on one side */ int side = (ci->filemask == 4) ? 2 : 1; From 35e47e3514b5129e6075a67fa9f4659da2f1a1a1 Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Tue, 15 Dec 2020 18:28:04 +0000 Subject: [PATCH 09/11] merge-ort: add implementation of rename collisions Implement rename/rename(2to1) and rename/add handling, i.e. a file is renamed into a location where another file is added (with that other file either being a plain add or itself coming from a rename). Note that rename collisions can also have a special case stacked on top: the file being renamed on one side of history is deleted on the other (yielding either a rename/add/delete conflict or perhaps a rename/rename(2to1)/delete[/delete]) conflict. One thing to note here is that when there is a double rename, the code in question only handles one of them at a time; a later iteration through the loop will handle the other. After they've both been handled, process_entry()'s normal add/add code can handle the collision. This code replaces the following from merge-recurisve.c: * all the 2to1 code in process_renames() * the RENAME_TWO_FILES_TO_ONE case of process_entry() * handle_rename_rename_2to1() * handle_rename_add() Also, there is some shared code from merge-recursive.c for multiple different rename cases which we will no longer need for this case (or other rename cases): * handle_file_collision() * setup_rename_conflict_info() The consolidation of six separate codepaths into one is made possible by a change in design: process_renames() tweaks the conflict_info entries within opt->priv->paths such that process_entry() can then handle all the non-rename conflict types (directory/file, modify/delete, etc.) orthogonally. This means we're much less likely to miss special implementation of some kind of combination of conflict types (see commits brought in by 66c62eaec6 ("Merge branch 'en/merge-tests'", 2020-11-18), especially commit ef52778708 ("merge tests: expect improved directory/file conflict handling in ort", 2020-10-26) for more details). That, together with letting worktree/index updating be handled orthogonally in the merge_switch_to_result() function, dramatically simplifies the code for various special rename cases. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 51 insertions(+), 3 deletions(-) diff --git a/merge-ort.c b/merge-ort.c index a10c3f5046..1c5b2f7e3b 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -795,10 +795,58 @@ static int process_renames(struct merge_options *opt, /* Need to check for special types of rename conflicts... */ if (collision && !source_deleted) { /* collision: rename/add or rename/rename(2to1) */ - die("Not yet implemented"); + const char *pathnames[3]; + struct version_info merged; + + struct conflict_info *base, *side1, *side2; + unsigned clean; + + pathnames[0] = oldpath; + pathnames[other_source_index] = oldpath; + pathnames[target_index] = newpath; + + base = strmap_get(&opt->priv->paths, pathnames[0]); + side1 = strmap_get(&opt->priv->paths, pathnames[1]); + side2 = strmap_get(&opt->priv->paths, pathnames[2]); + + VERIFY_CI(base); + VERIFY_CI(side1); + VERIFY_CI(side2); + + clean = handle_content_merge(opt, pair->one->path, + &base->stages[0], + &side1->stages[1], + &side2->stages[2], + pathnames, + 1 + 2 * opt->priv->call_depth, + &merged); + + memcpy(&newinfo->stages[target_index], &merged, + sizeof(merged)); + if (!clean) { + path_msg(opt, newpath, 0, + _("CONFLICT (rename involved in " + "collision): rename of %s -> %s has " + "content conflicts AND collides " + "with another path; this may result " + "in nested conflict markers."), + oldpath, newpath); + } } else if (collision && source_deleted) { - /* rename/add/delete or rename/rename(2to1)/delete */ - die("Not yet implemented"); + /* + * rename/add/delete or rename/rename(2to1)/delete: + * since oldpath was deleted on the side that didn't + * do the rename, there's not much of a content merge + * we can do for the rename. oldinfo->merged.is_null + * was already set, so we just leave things as-is so + * they look like an add/add conflict. + */ + + newinfo->path_conflict = 1; + path_msg(opt, newpath, 0, + _("CONFLICT (rename/delete): %s renamed " + "to %s in %s, but deleted in %s."), + oldpath, newpath, rename_branch, delete_branch); } else { /* * a few different cases...start by copying the From f1665e69188f54c941f9bf10ed388a72a91cc2a1 Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Tue, 15 Dec 2020 18:28:05 +0000 Subject: [PATCH 10/11] merge-ort: add implementation of normal rename handling Implement handling of normal renames. This code replaces the following from merge-recurisve.c: * the code relevant to RENAME_NORMAL in process_renames() * the RENAME_NORMAL case of process_entry() Also, there is some shared code from merge-recursive.c for multiple different rename cases which we will no longer need for this case (or other rename cases): * handle_rename_normal() * setup_rename_conflict_info() The consolidation of four separate codepaths into one is made possible by a change in design: process_renames() tweaks the conflict_info entries within opt->priv->paths such that process_entry() can then handle all the non-rename conflict types (directory/file, modify/delete, etc.) orthogonally. This means we're much less likely to miss special implementation of some kind of combination of conflict types (see commits brought in by 66c62eaec6 ("Merge branch 'en/merge-tests'", 2020-11-18), especially commit ef52778708 ("merge tests: expect improved directory/file conflict handling in ort", 2020-10-26) for more details). That, together with letting worktree/index updating be handled orthogonally in the merge_switch_to_result() function, dramatically simplifies the code for various special rename cases. (To be fair, the code for handling normal renames wasn't all that complicated beforehand, but it's still much simpler now.) Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/merge-ort.c b/merge-ort.c index 1c5b2f7e3b..26f357e524 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -870,7 +870,11 @@ static int process_renames(struct merge_options *opt, rename_branch, delete_branch); } else { /* normal rename */ - die("Not yet implemented"); + memcpy(&newinfo->stages[other_source_index], + &oldinfo->stages[other_source_index], + sizeof(newinfo->stages[0])); + newinfo->filemask |= (1 << other_source_index); + newinfo->pathnames[other_source_index] = oldpath; } } From 6fcccbd75556d1dcc80493f6eb51109f53a5dc83 Mon Sep 17 00:00:00 2001 From: Elijah Newren Date: Tue, 15 Dec 2020 18:28:06 +0000 Subject: [PATCH 11/11] merge-ort: add implementation of type-changed rename handling Implement cases where renames are involved in type changes (i.e. the side of history that didn't rename the file changed its type from a regular file to a symlink or submodule). There was some code to handle this in merge-recursive but only in the special case when the renamed file had no content changes. The code here works differently -- it knows process_entry() can handle mode conflicts, so it does a few minimal tweaks to ensure process_entry() can just finish the job as needed. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-ort.c | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) diff --git a/merge-ort.c b/merge-ort.c index 26f357e524..677c6a878c 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -777,8 +777,33 @@ static int process_renames(struct merge_options *opt, (S_ISREG(oldinfo->stages[other_source_index].mode) != S_ISREG(newinfo->stages[target_index].mode)); if (type_changed && collision) { - /* special handling so later blocks can handle this */ - die("Not yet implemented"); + /* + * special handling so later blocks can handle this... + * + * if type_changed && collision are both true, then this + * was really a double rename, but one side wasn't + * detected due to lack of break detection. I.e. + * something like + * orig: has normal file 'foo' + * side1: renames 'foo' to 'bar', adds 'foo' symlink + * side2: renames 'foo' to 'bar' + * In this case, the foo->bar rename on side1 won't be + * detected because the new symlink named 'foo' is + * there and we don't do break detection. But we detect + * this here because we don't want to merge the content + * of the foo symlink with the foo->bar file, so we + * have some logic to handle this special case. The + * easiest way to do that is make 'bar' on side1 not + * be considered a colliding file but the other part + * of a normal rename. If the file is very different, + * well we're going to get content merge conflicts + * anyway so it doesn't hurt. And if the colliding + * file also has a different type, that'll be handled + * by the content merge logic in process_entry() too. + * + * See also t6430, 'rename vs. rename/symlink' + */ + collision = 0; } if (source_deleted) { if (target_index == 1) { @@ -859,7 +884,11 @@ static int process_renames(struct merge_options *opt, newinfo->pathnames[0] = oldpath; if (type_changed) { /* rename vs. typechange */ - die("Not yet implemented"); + /* Mark the original as resolved by removal */ + memcpy(&oldinfo->stages[0].oid, &null_oid, + sizeof(oldinfo->stages[0].oid)); + oldinfo->stages[0].mode = 0; + oldinfo->filemask &= 0x06; } else if (source_deleted) { /* rename/delete */ newinfo->path_conflict = 1;