# Re: [RFC] Case insensitive Git attributes 6 messages from 2017-01-22 to 2017-01-24. Participants: Dakota Hawkins, Junio C Hamano, Lars Schneider. Thread: https://gitlist.dev/t/44941 ## Dakota Hawkins, 2017-01-22 19:25 Subject: Re: [RFC] Case insensitive Git attributes Message-ID: URL: https://gitlist.dev/e/CAHnyXxRx_iagZhki1rmVEpw%2BGZPWBRx7mNmahs3pruy57L3h-Q%40mail.gmail.com ``` Apologies for the delayed bump. I think because we're talking about affecting the behavior of .gitattributes that it would be better to have a distinct .gitattributes option, whether or not you also have a similar config option. Since .gitattributes is versioned and config options are not, I think this takes it out of the realm of personal preference. It's already too easy for somebody to screw up and not have a "required" filter driver (e.g. git lfs) configured and damage a repo by getting unnoticed and unfiltered content committed. I would love a .gitconfig option I could set that would let me stop manually ignoring case in globs for git commands, but this might actually make things worse for people if it were included as a config option only -- suddenly attributes could be applied to different files for different people. Of course, if git supported a subset of config options you could actually version and ensure everybody else has, this wouldn't be a problem ;) So, I think the correct (for today) solution is to have two options. One for .gitattributes globs and one for everything else. I realize that this might be somewhat controversial, so I wanted to see what everybody thought. ``` ## Junio C Hamano, 2017-01-23 18:35 Subject: Re: [RFC] Case insensitive Git attributes Message-ID: URL: https://gitlist.dev/e/xmqqvat5sjym.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Dakota Hawkins writes: > Apologies for the delayed bump. I think because we're talking about > affecting the behavior of .gitattributes that it would be better to > have a distinct .gitattributes option, whether or not you also have a > similar config option. As I know I am on the To: line of the message I am responding to, let me quicly let you know that I won't be responding to this thread for a while as I don't recall what the discussion was about. I will after I'll dig and find out what the thread was about but it won't happen immediately. Sorry about that. ``` ## Lars Schneider, 2017-01-23 18:42 Subject: Re: [RFC] Case insensitive Git attributes Message-ID: URL: https://gitlist.dev/e/C265204B-BCCF-4085-9933-F28EB459CFB9%40gmail.com In-Reply-To: ``` > On 23 Jan 2017, at 19:35, Junio C Hamano wrote: > > Dakota Hawkins writes: > >> Apologies for the delayed bump. I think because we're talking about >> affecting the behavior of .gitattributes that it would be better to >> have a distinct .gitattributes option, whether or not you also have a >> similar config option. > > As I know I am on the To: line of the message I am responding to, > let me quicly let you know that I won't be responding to this thread > for a while as I don't recall what the discussion was about. I will > after I'll dig and find out what the thread was about but it won't > happen immediately. Sorry about that. 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 Cheers, Lars ``` ## Junio C Hamano, 2017-01-23 19:25 Subject: Re: [RFC] Case insensitive Git attributes Message-ID: URL: https://gitlist.dev/e/xmqq1svtshnr.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Lars Schneider writes: > 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. ``` ## Junio C Hamano, 2017-01-23 19:38 Subject: Re: [RFC] Case insensitive Git attributes Message-ID: URL: https://gitlist.dev/e/xmqqwpdlr2ht.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Junio C Hamano 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. ``` ## Lars Schneider, 2017-01-24 09:49 Subject: Re: [RFC] Case insensitive Git attributes Message-ID: <77FC347D-574E-4A4C-8114-8AD14222279B@gmail.com> URL: https://gitlist.dev/e/77FC347D-574E-4A4C-8114-8AD14222279B%40gmail.com In-Reply-To: ``` > On 23 Jan 2017, at 20:38, Junio C Hamano wrote: > > Junio C Hamano 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. ```