admin/git
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

merge-ort: allow rename detection to be disabled

Browse Source 
When merge-ort was written, I did not at first allow rename detection to
be disabled, because I suspected that most folks disabling rename
detection were doing so solely for performance reasons.  Since I put a
lot of working into providing dramatic speedups for rename detection
performance as used by the merge machinery, I wanted to know if there
were still real world repositories where rename detection was
problematic from a performance perspective.  We have had years now to
collect such information, and while we never received one, waiting
longer with the option disabled seems unlikely to help surface such
issues at this point.  Also, there has been at least one request to
allow rename detection to be disabled for behavioral rather than
performance reasons (see the thread including
https://lore.kernel.org/git/CABPp-BG-Nx6SCxxkGXn_Fwd2wseifMFND8eddvWxiZVZk0zRaA@mail.gmail.com/
), so let's start heeding the config and command line settings.

Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Elijah Newren
2025-03-13 02:46:37 +00:00
committed by Junio C Hamano
parent 4e5d9de96c
commit a707d4f941
3 changed files with 17 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
Documentation/merge-strategies.adoc
View File

@@ -82,6 +82,11 @@ find-renames[=<n>];;
rename-threshold=<n>;;
Deprecated synonym for `find-renames=<n>`.
no-renames;;
Turn off rename detection. This overrides the `merge.renames`
configuration variable.
See also linkgit:git-diff[1] `--no-renames`.
subtree[=<path>];;
This option is a more advanced form of 'subtree' strategy, where
the strategy makes a guess on how two trees must be shifted to
@@ -107,7 +112,7 @@ For a path that is a submodule, the same caution as 'ort' applies to this
strategy.
+
The 'recursive' strategy takes the same options as 'ort'. However,
there are three additional options that 'ort' ignores (not documented
there are two additional options that 'ort' ignores (not documented
above) that are potentially useful with the 'recursive' strategy:
patience;;
@@ -121,11 +126,6 @@ diff-algorithm=[patience|minimal|histogram|myers];;
specifically uses `diff-algorithm=histogram`, while `recursive`
defaults to the `diff.algorithm` config setting.
no-renames;;
Turn off rename detection. This overrides the `merge.renames`
configuration variable.
See also linkgit:git-diff[1] `--no-renames`.
resolve::
This can only resolve two heads (i.e. the current branch
and another branch you pulled from) using a 3-way merge

5
merge-ort.c
View File

@@ -3448,6 +3448,11 @@ static int detect_and_process_renames(struct merge_options *opt)
if (!possible_renames(renames))
goto cleanup;
if (!opt->detect_renames) {
renames->redo_after_renames = 0;
renames->cached_pairs_valid_side = 0;
goto cleanup;
}
trace2_region_enter("merge", "regular renames", opt->repo);
detection_run |= detect_regular_renames(opt, MERGE_SIDE1);

6
t/t4301-merge-tree-write-tree.sh
View File

@@ -73,6 +73,12 @@ test_expect_success 'Clean merge' '
test_cmp expect actual
'
# Repeat the previous test, but turn off rename detection
test_expect_success 'Failed merge without rename detection' '
test_must_fail git -c diff.renames=false merge-tree --write-tree side1 side3 >out &&
grep "CONFLICT (modify/delete): numbers deleted" out
'
test_expect_success 'Content merge and a few conflicts' '
git checkout side1^0 &&
test_must_fail git merge side2 &&