| commit | 002a6dfc7c4642524d1e82f8cf994fc9ea5786f9 | |
| author | Elijah Newren <newren@gmail.com> | |
| Wed, 4 Aug 2021 23:50:49 +0000 (4 23:50 +0000) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Thu, 5 Aug 2021 15:57:40 +0000 (5 08:57 -0700) | ||
| tree | 9b244d002f6d5e536ec673a0d20d09d248fa4fd2 | treesnapshot (tar.gz zip) |
| parent | 510415ecc9d6ff4a99991dc1b70a1ac50818a539 | commitdiff |
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>
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 | diffblobblamehistory |