]> git.ipfire.org Git - thirdparty/git.git/commitdiff
Merge branch 'en/merge-ort-restart-optim-fix'
authorJunio C Hamano <gitster@pobox.com>
Wed, 9 Feb 2022 22:20:58 +0000 (14:20 -0800)
committerJunio C Hamano <gitster@pobox.com>
Wed, 9 Feb 2022 22:20:58 +0000 (14:20 -0800)
The merge-ort misbehaved when merge.renameLimit configuration is
set too low and failed to find all renames.

* en/merge-ort-restart-optim-fix:
  merge-ort: avoid assuming all renames detected

merge-ort.c
t/t6429-merge-sequence-rename-caching.sh

index c319797021938a9df635c8db146ac6555331c7db..b0ff9a728793aa6a3f063d20139408f8c2746c47 100644 (file)
@@ -3060,6 +3060,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;
index 035edc40b1ebba46305fb555c903d8b44220f8de..f2bc8a7d2a20f4b6acf19b72f03defb4fa667bbb 100755 (executable)
@@ -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