Hi Michael, On Tue, 29 Dec 2015, Michael Haggerty wrote: > On 09/28/2015 06:12 PM, Johannes Schindelin wrote: > > Git has a config variable to indicate that it is operating on a file > > system that is case-insensitive: core.ignoreCase. But the > > `dir_inside_of()` function did not respect that. As a result, if Git's > > idea of the current working directory disagreed in its upper/lower case > > with the `GIT_WORK_TREE` variable (e.g. `C:\test` vs `c:\test`) the > > user would be greeted by the error message > > > > fatal: git-am cannot be used without a working tree. > > > > when trying to run a rebase. > > > > This fixes https://github.com/git-for-windows/git/issues/402 (reported by > > Daniel Harding). > > I was just going through the 2.7 release notes when I saw this patch. Thanks for your diligence! > My understanding was that many of the case-insensitive filesystems also > support Unicode. Is the byte-oriented code in this patch adequate? I > would have thought it necessary to use a Unicode-aware algorithm here, > that knows: > > * that bytes != characters I am not sure that we can in general assume that the file name is UTF-8... Or does Git always assume that? > * how to do a case-insensitive comparison of strings that include > non-ASCII characters I was worrying about that, too, but decided to punt on it when I realized that no other case-insensitive code in Git bothers about those characters. > * (possibly) insensitivity to NFC vs. NFD vs. non-normalized forms Whoa... I really would like to stay away from that collection of potholes... > I suppose that such OSs have built-in functions for deciding whether two > paths are equivalent. Possibly these could be used? We could, in theory, try to do that, but what about the OSes that do *not* have those functions? We would need our own fallback anyway, so why not guarantee consistency and use our own functions only? Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html