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@xxxxxxxxx> --- After thinking for a while about my RFC at https://public-inbox.org/git/CABPp-BF4gbwVRHA3D1vqXuSnh3aS9XVLqtEUEmfmLDKPccyxtA@xxxxxxxxxxxxxx/ 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
