merge-ort: avoid assuming all renames detected

In commit 8b09a900a1 ("merge-ort: restart merge with cached renames to
reduce process entry cost", 2021-07-16), we noted that in the merge-ort
steps of
    collect_merge_info()
    detect_and_process_renames()
    process_entries()
that process_entries() was expensive, and we could often make it cheaper
by changing this to
    collect_merge_info()
    detect_and_process_renames()
    <cache all the renames, and restart>
    collect_merge_info()
    detect_and_process_renames()
    process_entries()
because the second collect_merge_info() would be cheaper (we could avoid
traversing into some directories), the second
detect_and_process_renames() would be free since we had already detected
all renames, and then process_entries() has far fewer entries to handle.

However, this was built on the assumption that the first
detect_and_process_renames() actually detected all potential renames.
If someone has merge.renameLimit set to some small value, that
assumption is violated which manifests later with the following message:

    $ git -c merge.renameLimit=1 rebase upstream
    ...
    git: merge-ort.c:546: clear_or_reinit_internal_opts: Assertion
    `renames->cached_pairs_valid_side == 0' failed.

Turn off this cache-renames-and-restart whenever we cannot detect all
renames, and add a testcase that would have caught this problem.

Reported-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Tested-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/merge-ort.c b/merge-ort.c
index b346e23ff2cbeb3ea1ced62b80419af5ed613071..7b2c0e9ee2b10f9c25ee5f3b4ef79aa02387ea11 100644 (file)
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -3031,6 +3031,10 @@ static int detect_and_process_renames(struct merge_options *opt,
        trace2_region_enter("merge", "regular renames", opt->repo);
        detection_run |= detect_regular_renames(opt, MERGE_SIDE1);
        detection_run |= detect_regular_renames(opt, MERGE_SIDE2);
+       if (renames->needed_limit) {
+               renames->cached_pairs_valid_side = 0;
+               renames->redo_after_renames = 0;
+       }
        if (renames->redo_after_renames && detection_run) {
                int i, side;
                struct diff_filepair *p;

diff --git a/t/t6429-merge-sequence-rename-caching.sh b/t/t6429-merge-sequence-rename-caching.sh
index 035edc40b1ebba46305fb555c903d8b44220f8de..f2bc8a7d2a20f4b6acf19b72f03defb4fa667bbb 100755 (executable)
--- a/t/t6429-merge-sequence-rename-caching.sh
+++ b/t/t6429-merge-sequence-rename-caching.sh
@@ -697,4 +697,71 @@ test_expect_success 'caching renames only on upstream side, part 2' '
        )
 '
 
+#
+# The following testcase just creates two simple renames (slightly modified
+# on both sides but without conflicting changes), and a directory full of
+# files that are otherwise uninteresting.  The setup is as follows:
+#
+#   base:     unrelated/<BUNCH OF FILES>
+#             numbers
+#             values
+#   upstream: modify: numbers
+#             modify: values
+#   topic:    add: unrelated/foo
+#             modify: numbers
+#             modify: values
+#             rename: numbers -> sequence
+#             rename: values -> progression
+#
+# This is a trivial rename case, but we're curious what happens with a very
+# low renameLimit interacting with the restart optimization trying to notice
+# that unrelated/ looks like a trivial merge candidate.
+#
+test_expect_success 'avoid assuming we detected renames' '
+       git init redo-weirdness &&
+       (
+               cd redo-weirdness &&
+
+               mkdir unrelated &&
+               for i in $(test_seq 1 10)
+               do
+                       >unrelated/$i
+               done &&
+               test_seq  2 10 >numbers &&
+               test_seq 12 20 >values &&
+               git add numbers values unrelated/ &&
+               git commit -m orig &&
+
+               git branch upstream &&
+               git branch topic &&
+
+               git switch upstream &&
+               test_seq  1 10 >numbers &&
+               test_seq 11 20 >values &&
+               git add numbers &&
+               git commit -m "Some tweaks" &&
+
+               git switch topic &&
+
+               >unrelated/foo &&
+               test_seq  2 12 >numbers &&
+               test_seq 12 22 >values &&
+               git add numbers values unrelated/ &&
+               git mv numbers sequence &&
+               git mv values progression &&
+               git commit -m A &&
+
+               #
+               # Actual testing
+               #
+
+               git switch --detach topic^0 &&
+
+               test_must_fail git -c merge.renameLimit=1 rebase upstream &&
+
+               git ls-files -u >actual &&
+               ! test_file_is_empty actual
+       )
+'
+
 test_done