From: Philip Oakley Date: Fri, 10 Nov 2017 22:27:19 GMT Subject: Re: [PATCH 00/30] Add directory rename detection to git Message-ID: <3076EE0E678D43B286F86E622CB9F06E@PhilipOakley> In-Reply-To: <20171110190550.27059-1-newren@gmail.com> From: "Elijah Newren" > [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 -- Philip