mirror of
https://github.com/git/git
synced 2024-08-25 10:45:59 +00:00
merge-strategies.txt: do not imply using copy detection is desired
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>
This commit is contained in:
parent
510415ecc9
commit
002a6dfc7c
|
@ -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:
|
||||
|
||||
|
|
Loading…
Reference in a new issue