From: "Elijah Newren" <newren@xxxxxxxxx>
[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
