Jeff King <peff@xxxxxxxx> writes: > On Thu, Mar 22, 2012 at 09:00:31PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > >> Maybe: >> --- 8< --- >> When set, case-insensitive comparisons will be used when internally >> comparing file names. >> >> The default is false, but when a new repository is created by >> git-clone[1] or git-init[1], git will probe the filesystem and set it >> to `true` if the filesystem is case-insensitive. >> >> On case-insensitive filesystems like FAT, NTFS and HSF+, names that >> differ only in capitalization, like "Makefile" and "makefile", refer >> to the same file. While such filesystems usually preserve the >> capitalization used during file creation, tools designed for such >> filesystems will often modify capitalization when saving files and >> when displaying filenames. Enabling core.ignorecase causes git to >> ignore case-only differences in file names. >> >> Enabling core.ignorecase on a case insensitive filesystem does >> not make sense, because filenames with different capitalization will >> still be treated as different by the filesystem. >> --- >8 --- > > From his response, I guess Junio does not agree, but this is my favorite > of the texts proposed so far. I do not care too deeply, as long as we do not paint ourselves in a corner by saying things that we do not have to say and end up sounding as if we are defining what the undefined behaviour should be. If the change of the presentation order seen above is reverted (in other words, drop the first paragraph, move the second paragraph to the very end), I wouldn't mind the above too much. > PS If we do use it, it needs s/HSF/HFS/. That too. -- 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