[PATCH v2 05/10] merge-strategies.txt: do not imply using copy detection is desired

From: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>
Date: Aug 4, 2021, 05:28 UTC
Message-ID: <b1db5fdebe5529d9630129dc7ee5ab0eff6adf69.1628054936.git.gitgitgadget@gmail.com>
In-Reply-To: <pull.1059.v2.git.git.1628054935.gitgitgadget@gmail.com>

From: Elijah Newren <newren@gmail.com>

Stating that the recursive strategy "currently cannot make use of detected copies" implies that this is a technical shortcoming of the current algorithm. I disagree with that. I don't see how copies could possibly be used in a sane fashion in a merge algorithm -- would we propagate changes in one file on one side of history to each copy of that file when merging? That makes no sense to me. I cannot think of anything else that would make sense either. Change the wording to simply state that we ignore any copies.

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 Documentation/merge-strategies.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index f100fad1e43..e2988124581 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -16,9 +16,9 @@ recursive::
 	causing mismerges by tests done on actual merge commits
 	taken from Linux 2.6 kernel development history.
 	Additionally this can detect and handle merges involving
-	renames, but currently cannot make use of detected
-	copies.  This is the default merge strategy when pulling
-	or merging one branch.
+	renames.  It does not make use of detected copies.  This
+	is the default merge strategy when pulling or merging one
+	branch.
 +
 The 'recursive' strategy can take the following options:

-- 
gitgitgadget