Re: [RFC] Case insensitive Git attributes

> On 23 Jan 2017, at 20:38, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Junio C Hamano <gitster@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.