merge-ort: handle interactions of caching and rename/rename(1to1) cases
As documented in Documentation/technical/remembering-renames.txt, and as tested for in the two testcases in t6429 with "rename same file identically" in their description, there is one case where we need to have renames in one commit NOT be cached for the next commit in our rebase sequence -- namely, rename/rename(1to1) cases. Rather than specifically trying to uncache those and fix up dir_rename_counts() to match (which would also be valid but more work), we simply disable the optimization when this really rare type of rename occurs. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren committed
May 20, 2021 at 06:09 UTC
cbdca289fbb011e7397fecfebeeac3f887ef22d1
1 file changed
+29
-1
merge-ort.c
+29
-1
@@ -2111,6 +2111,9 @@ static int process_renames(struct merge_options *opt,
2111
VERIFY_CI(side2);
2112
2113
if (!strcmp(pathnames[1], pathnames[2])) {
2114
+ struct rename_info *ri = &opt->priv->renames;
2115
+ int j;
2116
+
2117
/* Both sides renamed the same way */
2118
assert(side1 == side2);
2119
memcpy(&side1->stages[0], &base->stages[0],
@@ -2120,6 +2123,16 @@ static int process_renames(struct merge_options *opt,
2123
base->merged.is_null = 1;
2124
base->merged.clean = 1;
2125
2126
+ /*
2127
+ * Disable remembering renames optimization;
2128
+ * rename/rename(1to1) is incredibly rare, and
2129
+ * just disabling the optimization is easier
2130
+ * than purging cached_pairs,
2131
+ * cached_target_names, and dir_rename_counts.
2132
+ */
2133
+ for (j = 0; j < 3; j++)
2134
+ ri->merge_trees[j] = NULL;
2135
+
2136
/* We handled both renames, i.e. i+1 handled */
2137
i++;
2138
/* Move to next rename */
@@ -3918,7 +3931,22 @@ static void merge_check_renames_reusable(struct merge_options *opt,
3931
3932
renames = &opti->renames;
3933
merge_trees = renames->merge_trees;
3921
- /* merge_trees[0..2] will only be NULL if opti is */
3934
+
3935
+ /*
3936
+ * Handle case where previous merge operation did not want cache to
3937
+ * take effect, e.g. because rename/rename(1to1) makes it invalid.
3938
+ */
3939
+ if (!merge_trees[0]) {
3940
+ assert(!merge_trees[0] && !merge_trees[1] && !merge_trees[2]);
3941
+ renames->cached_pairs_valid_side = 0; /* neither side valid */
3942
+ return;
3943
+ }
3944
+
3945
+ /*
3946
+ * Handle other cases; note that merge_trees[0..2] will only
3947
+ * be NULL if opti is, or if all three were manually set to
3948
+ * NULL by e.g. rename/rename(1to1) handling.
3949
+ */
3950
assert(merge_trees[0] && merge_trees[1] && merge_trees[2]);
3951
3952
/* Check if we meet a condition for re-using cached_pairs */