Hi Elijah, On Tue, 3 Aug 2021, Elijah Newren via GitGitGadget wrote: > From: Elijah Newren <newren@xxxxxxxxx> > > 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. FWIW I fully agree with this reasoning. Ciao, Dscho > > Signed-off-by: Elijah Newren <newren@xxxxxxxxx> > --- > 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 6b6017e1cc8..bc82799365a 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 > >