[PATCH] RelNotes 2.18: clarify where directory rename detection applies

[PATCH] RelNotes 2.18: clarify where directory rename detection applies

[Elijah Newren]

Mention that this feature works with some commands (merge and cherry-pick,
implying that it also works with commands that build on these like rebase
-m and rebase -i).  Explicitly mentioning two commands hopefully implies
that it may not always work with other commands (am, and rebase without
flags that imply either -m or -i).

Also, since the directory rename detection from this cycle was
specifically added in merge-recursive and not diffcore-rename, remove the
'in "diff" family" phrase from the note.  (Folks have requested in the
past that `git diff` detect directory renames and somehow simplify its
output, so it may be helpful to avoid implying that diff has any new
capability here.)

Signed-off-by: Elijah Newren <newren@gmail.com>
---
After thinking for a while about my RFC at
  https://public-inbox.org/git/CABPp-BF4gbwVRHA3D1vqXuSnh3aS9XVLqtEUEmfmLDKPccyxtA@mail.gmail.com/
this commit seems like a simple fix.  We can discuss during the 2.19 and
2.20 cycles what to do with rebase, if anything.

Also, if the above commit message feels incomplete without an explanation
of why directory rename detection doesn't work with git-am, the following
could be included:


More details about the git-am limitation for the curious:

git-am tries to avoid a full three way merge, instead calling git-apply.
That prevents us from detecting renames at all, which may defeat the
directory rename detection.  There is a fallback, though; if the initial
git-apply fails and the user has specified the -3 option, git-am will
fall back to a three way merge.  However, git-am lacks the necessary
information to do a "real" three way merge.  Instead, it has to use
build_fake_ancestor() to get a merge base that is missing files whose
rename may have been important to detect for directory rename detection
to function.

am-based rebases work by first generating a bunch of patches (which no
longer record what the original commits were and thus don't have the
necessary info from which we can find a real merge-base), and then
calling `git am`.  This implies that am-based rebases will not always
successfully detect directory renames either.  merged-based rebases
(rebase -m) and cherry-pick-based rebases (rebase -i) are not affected
by this shortcoming.

 Documentation/RelNotes/2.18.0.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/RelNotes/2.18.0.txt b/Documentation/RelNotes/2.18.0.txt
index ed80e5485b..449e49e0eb 100644
--- a/Documentation/RelNotes/2.18.0.txt
+++ b/Documentation/RelNotes/2.18.0.txt
@@ -6,7 +6,7 @@ Updates since v2.17
 
 UI, Workflows & Features
 
- * Rename detection logic in "diff" family that is used in "merge" has
+ * Rename detection logic that is used in "merge" and "cherry-pick" has
    learned to guess when all of x/a, x/b and x/c have moved to z/a,
    z/b and z/c, it is likely that x/d added in the meantime would also
    want to move to z/d by taking the hint that the entire directory
-- 
2.18.0.rc0.3.gda9bce4c68

Re: [PATCH] RelNotes 2.18: clarify where directory rename detection applies

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

> Also, since the directory rename detection from this cycle was
> specifically added in merge-recursive and not diffcore-rename, remove the
> 'in "diff" family" phrase from the note.

Thanks.