Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > On 10/06/2011 08:22 PM, Brandon Casey wrote: >> The last set of tests is performed only on a case-insensitive filesystem. >> Those tests make sure that git handles the case where the .gitignore file >> resides in a subdirectory and the user supplies a path that does not match >> the case in the filesystem. In that case^H^H^H^Hsituation, part of the >> path supplied by the user is effectively interpreted case-insensitively, >> and part of it is dependent on the setting of core.ignorecase. git should >> only match the portion of the path below the directory holding the >> .gitignore file according to the setting of core.ignorecase. > > ... It is hard to imagine that > anybody *wants* part of a single filename to be matched > case-insensitively and another part to be matched case-sensitively. That is not necessarily coming from the user's wish. When a command that takes a pathspec from the user is run from a subdirectory, almost always the output from $(git rev-parse --show-prefix) is prefixed to them. This value is read from the filesystem, and unless on a system whose readdir() may lie to us, we do not _have_ to ignore the case of this part of the substring of a resulting pathspec element to get a successful match, even though we _do_ want to match the user-supplied part case insensitively if/when the user says he wants us to with core.ignorecase. Having said that, it may not hurt in practice if we matched the prefix part case insensitvely, because prefix=foobar/ obtained on a filesystem where core.ignorecase is true would mean there won't be FooBar/ and other case-permuted names on the filesystem at the same time. But of course I may be missing something... -- 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