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