Junio C Hamano <gits...@pobox.com> writes: > So you are worried about the case where somebody on a case > insensitive but case preserving system would do > > $ edit file.txt > $ edit .gitattributes > $ git add file.txt .gitattributes > > and adds "*.TXT someattr=true" to the attributes file, which > would set someattr to true on his system for file.txt, but when the > result is checked out on a case sensitive system, it would behave > differently because "*.TXT" does not match "file.txt"? > > How do other systems address it? Your Java, Ruby, etc. sources may > refer to another file with "import" and the derivation of the file > names from class names or package names would have the same issue, > isn't it? Do they have an option that lets you say > > Even though the import statements may say "import a.b.C", we > know that the source tarball was prepared on a case insensitive > system, and I want you to look for a/b/C.java and a/b/c.java and > use what was found. > > or something like that? Same for anything that records other > filenames in the content to refer to them, like "Makefile". > > My knee jerk reaction to that is that .gitattributes and .gitignore > should not be instructed to go case insensitive on case sensitive > systems. If the system is case insensitive but case preserving, > it probably would make sense not to do case insensitive matching, > which would prevent the issue from happening in the first place.
Sorry, but there is a slight leap in the above that makes it hard to track my thought, so let me clarify a bit. In the above, I am guessing the answer to the "How do other systems address it?" question to be "nothing". And that leads to the conclusion that it is better to do "nothing on case sensitive systems, and probably become evem more strict on case insensitive but case preserving systems", because that will give us a chance to expose the problem earlier, hopefully even on the originating system.
