From: "Elijah Newren" <redacted>

[This series is entirely independent of my rename detection limits series.
However, I have a separate rename detection performance series that 
depends
on both this series and the rename detection limits series.]

In this patchset, I introduce directory rename detection to 
merge-recursive,
predominantly so that when files are added to directories on one side of
history and those directories are renamed on the other side of history, 
the
files will end up in the proper location after a merge or cherry-pick.

However, this isn't limited to that simplistic case.  More interesting
possibilities exist, such as:

 * a file being renamed into a directory which is renamed on the other
   side of history, causing the need for a transitive rename.

How does this cope with the case insensitive case preserving file systems on 
Mac and Windows, esp when core.ignorecase is true. If it's a bigger problem 
that the series already covers, would the likely changes be reasonably 
localised?

This came up recently on GfW for `git checkout` of a branch where the case 
changed ("Test" <-> "test"), but git didn't notice that it needed to rename 
the directories on such an file system. 
https://github.com/git-for-windows/git/issues/1333

<snip>

--
Philip