Re: [RFC] Case insensitive Git attributes

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 23, 2017, 19:25 UTC
Message-ID: <xmqq1svtshnr.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <C265204B-BCCF-4085-9933-F28EB459CFB9@gmail.com>

Lars Schneider <larsxschneider@gmail.com> writes:

Show 14 quoted lines

> Problem:
> Git attributes for path names are generally case sensitive. However, on 
> a case insensitive file system (e.g. macOS/Windows) they appear to be
> case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That 
> works great until a Git users joins the party with a case sensitive file 
> system. For this Git user the attributes pattern only matches files with
> the exact case (*.bar` would match only `foo.bar`).
>
> Question/Proposal:
> Could we introduce some flag to signal that certain attribute patterns
> are always case insensitive? 
>
> Thread:
> http://public-inbox.org/git/C83BE22D-EAC8-49E2-AEE3-22D4A99AE205@gmail.com/#t

Thanks for a pointer.

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.