]> git.ipfire.org Git - thirdparty/git.git/commitdiff
merge-strategies.txt: do not imply using copy detection is desired
authorElijah Newren <newren@gmail.com>
Wed, 4 Aug 2021 23:50:49 +0000 (23:50 +0000)
committerJunio C Hamano <gitster@pobox.com>
Thu, 5 Aug 2021 15:57:40 +0000 (08:57 -0700)
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.

Acked-by: Derrick Stolee <dstolee@microsoft.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/merge-strategies.txt

index f100fad1e43a6c11a2e0c3289bb2aa2f0d412e92..e2988124581f58fd895e0522a6da4729b224adf5 100644 (file)
@@ -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: