Torsten Bögershausen <tboegi@xxxxxx> writes: > On 2014-02-01 10.14, Reuben Hawkins wrote: >> Most case-insensitive filesystems are case-preserving. In these >> filesystems (such as HFS+ on OS X) you can name a file Filename.txt, >> then rename the file to FileName.txt. That file will be accessible >> by both filenames, but the case is otherwise honored. We don't want >> to have git ignore case on these case-preserving filesystem >> implementations. > > Yes, we want. > Because the file system will treat "Filename.txt" and "FileName.txt" > the same. Another important thing to remember is that we cannot have these two files at the same time on such a filesystem. Somebody may have Filename.txt in the commit at the tip of the history, you clone/fetch and check it out, and you will have Filename.txt with the original contents. We do not try to corrupt the filename on core.ignorecase filesystem by any canonicalization. But then you may edit that file, and you either deliberately or without knowing (because some of your tools do this behind your back) may end up saving the result as FileName.txt. What happens? When we ask "what is the contents of Filename.txt now?" (using the original name still in the index) to the underlying system, we will be given what you placed in FileName.txt. We won't see "You do not have Filename.txt, but you now have FileName.txt". And that is the behaviour the end users (of not Git, but of a platform with such a filesystem) do expect from their tools. They do not want to see "You no longer have Filename.txt, and you have a new file FileName.txt". Now think what "git add Filename.txt" should do at that point? It should not say "I was told to add Filename.txt, but there is no such file, so I'll add nothing". If you run "git add -u Filename.txt", it should not say "I was told to add Filename.txt, but there is no such file, so I'll remove existing Filename.txt from the index". It must pick up the updated contents from your new FileName.txt, update the index entry "Filename.txt", and the next "git commit" must record it as an update to the same file. If you are on the other hand trying to correct an earlier mistake of having named the file "Filename.txt" but you now want to rename it "FileName.txt", the above behaviour by core.ignorecase may make it a bit cumbersome to do. You can first remove it from the index and then re-add it, I would think, as a workaround. Having to do a "workaround" is unfortunate but it is an unavoidable consequence of having to choose between the two and having to pick one. Most of the time you do not want such a rename (or rather, the loss of the file Filename.txt and the creation of the unrelated FileName.txt) and a change from Filename.txt to FileName.txt is most likely to be a mistake in the platform tool that mucked with the files on your filesystem, so we choose to make it easy for the user not to be disturbed by such a change. -- 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