> On 23 Jan 2017, at 20:38, Junio C Hamano <[email protected]> wrote:
>
> Junio C Hamano <[email protected]> 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"?
Correct!
>> 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.
I agree: Git attributes should behave the same on all platforms independent
of the file system type. I dug a bit deeper and realized that this is actually
already the case. However, the default (?) core.ignorecase=1 config on Win/Mac
generates the behavior explained above. I wonder if 6eba621 ("attr.c: respect
core.ignorecase when matching attribute patterns", 2011-10-11) was a good idea.
AFAIK disabling core.ignorecase entirely on Win/Mac is no solution as this would
generate other trouble.
Git users can already create case insensitive gitattributes pattern. E.g.:
*.[tT][xX][tT]
However, based on my dayjob experience no Win/Mac developer does that as it
makes the gitattributes file unreadable. Consequently, Linux developers are
screwed. Therefore, I wonder if it would make sense to introduce a shortcut
for the case insensitive glob pattern. E.g.:
*.txt ignorecase
If Git detects the ignorecase attribute then it could generate *.[tT][xX][tT]
automatically.
