{"thread":{"id":"44941","subject":"Re: [RFC] Case insensitive Git attributes","startedAt":"2017-01-22T19:26:05Z","lastAt":"2017-01-24T09:49:12Z","messageCount":6,"participants":["Dakota Hawkins","Junio C Hamano","Lars Schneider"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"309938","messageId":"CAHnyXxRx_iagZhki1rmVEpw+GZPWBRx7mNmahs3pruy57L3h-Q@mail.gmail.com","threadId":"44941","inReplyTo":null,"subject":"Re: [RFC] Case insensitive Git attributes","fromName":"Dakota Hawkins","fromEmail":"dakota@dakotahawkins.com","sentAt":"2017-01-22T19:25:58Z","receivedAt":"2017-01-22T19:26:05Z","isPatch":false,"sender":{"key":"dakota@dakotahawkins.com","avatar":null},"body":"Apologies for the delayed bump. I think because we're talking about\naffecting the behavior of .gitattributes that it would be better to\nhave a distinct .gitattributes option, whether or not you also have a\nsimilar config option.\n\nSince .gitattributes is versioned and config options are not, I think\nthis takes it out of the realm of personal preference. It's already\ntoo easy for somebody to screw up and not have a \"required\" filter\ndriver (e.g. git lfs) configured and damage a repo by getting\nunnoticed and unfiltered content committed.\n\nI would love a .gitconfig option I could set that would let me stop\nmanually ignoring case in globs for git commands, but this might\nactually make things worse for people if it were included as a config\noption only -- suddenly attributes could be applied to different files\nfor different people.\n\nOf course, if git supported a subset of config options you could\nactually version and ensure everybody else has, this wouldn't be a\nproblem ;)\n\nSo, I think the correct (for today) solution is to have two options.\nOne for .gitattributes globs and one for everything else. I realize\nthat this might be somewhat controversial, so I wanted to see what\neverybody thought.\n"},{"id":"309994","messageId":"xmqqvat5sjym.fsf@gitster.mtv.corp.google.com","threadId":"44941","inReplyTo":"CAHnyXxRx_iagZhki1rmVEpw+GZPWBRx7mNmahs3pruy57L3h-Q@mail.gmail.com","subject":"Re: [RFC] Case insensitive Git attributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-23T18:35:29Z","receivedAt":"2017-01-23T18:35:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dakota Hawkins writes:\n\n> Apologies for the delayed bump. I think because we're talking about\n> affecting the behavior of .gitattributes that it would be better to\n> have a distinct .gitattributes option, whether or not you also have a\n> similar config option.\n\nAs I know I am on the To: line of the message I am responding to,\nlet me quicly let you know that I won't be responding to this thread\nfor a while as I don't recall what the discussion was about. I will\nafter I'll dig and find out what the thread was about but it won't\nhappen immediately. Sorry about that.\n"},{"id":"309997","messageId":"C265204B-BCCF-4085-9933-F28EB459CFB9@gmail.com","threadId":"44941","inReplyTo":"xmqqvat5sjym.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC] Case insensitive Git attributes","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-01-23T18:42:40Z","receivedAt":"2017-01-23T18:42:47Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 23 Jan 2017, at 19:35, Junio C Hamano wrote:\n> \n> Dakota Hawkins writes:\n> \n>> Apologies for the delayed bump. I think because we're talking about\n>> affecting the behavior of .gitattributes that it would be better to\n>> have a distinct .gitattributes option, whether or not you also have a\n>> similar config option.\n> \n> As I know I am on the To: line of the message I am responding to,\n> let me quicly let you know that I won't be responding to this thread\n> for a while as I don't recall what the discussion was about. I will\n> after I'll dig and find out what the thread was about but it won't\n> happen immediately. Sorry about that.\n\n\nProblem:\nGit attributes for path names are generally case sensitive. However, on \na case insensitive file system (e.g. macOS/Windows) they appear to be\ncase insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That \nworks great until a Git users joins the party with a case sensitive file \nsystem. For this Git user the attributes pattern only matches files with\nthe exact case (*.bar` would match only `foo.bar`).\n\nQuestion/Proposal:\nCould we introduce some flag to signal that certain attribute patterns\nare always case insensitive? \n\nThread:\nhttp://public-inbox.org/git/C83BE22D-EAC8-49E2-AEE3-22D4A99AE205@gmail.com/#t\n\nCheers,\nLars\n"},{"id":"310002","messageId":"xmqq1svtshnr.fsf@gitster.mtv.corp.google.com","threadId":"44941","inReplyTo":"C265204B-BCCF-4085-9933-F28EB459CFB9@gmail.com","subject":"Re: [RFC] Case insensitive Git attributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-23T19:25:12Z","receivedAt":"2017-01-23T19:25:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider writes:\n\n> Problem:\n> Git attributes for path names are generally case sensitive. However, on \n> a case insensitive file system (e.g. macOS/Windows) they appear to be\n> case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That \n> works great until a Git users joins the party with a case sensitive file \n> system. For this Git user the attributes pattern only matches files with\n> the exact case (*.bar` would match only `foo.bar`).\n>\n> Question/Proposal:\n> Could we introduce some flag to signal that certain attribute patterns\n> are always case insensitive? \n>\n> Thread:\n> http://public-inbox.org/git/C83BE22D-EAC8-49E2-AEE3-22D4A99AE205@gmail.com/#t\n\nThanks for a pointer.\n\nSo you are worried about the case where somebody on a case\ninsensitive but case preserving system would do\n\n $ edit file.txt\n $ edit .gitattributes\n $ git add file.txt .gitattributes\n\nand adds \"*.TXT\tsomeattr=true\" to the attributes file, which\nwould set someattr to true on his system for file.txt, but when the\nresult is checked out on a case sensitive system, it would behave\ndifferently because \"*.TXT\" does not match \"file.txt\"?\n\nHow do other systems address it? Your Java, Ruby, etc. sources may\nrefer to another file with \"import\" and the derivation of the file\nnames from class names or package names would have the same issue,\nisn't it? Do they have an option that lets you say\n\n Even though the import statements may say \"import a.b.C\", we\n know that the source tarball was prepared on a case insensitive\n system, and I want you to look for a/b/C.java and a/b/c.java and\n use what was found.\n\nor something like that? Same for anything that records other\nfilenames in the content to refer to them, like \"Makefile\".\n\nMy knee jerk reaction to that is that .gitattributes and .gitignore\nshould not be instructed to go case insensitive on case sensitive\nsystems. If the system is case insensitive but case preserving,\nit probably would make sense not to do case insensitive matching,\nwhich would prevent the issue from happening in the first place.\n\n\n"},{"id":"310003","messageId":"xmqqwpdlr2ht.fsf@gitster.mtv.corp.google.com","threadId":"44941","inReplyTo":"xmqq1svtshnr.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC] Case insensitive Git attributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-23T19:38:06Z","receivedAt":"2017-01-23T19:38:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> So you are worried about the case where somebody on a case\n> insensitive but case preserving system would do\n>\n> $ edit file.txt\n> $ edit .gitattributes\n> $ git add file.txt .gitattributes\n>\n> and adds \"*.TXT\tsomeattr=true\" to the attributes file, which\n> would set someattr to true on his system for file.txt, but when the\n> result is checked out on a case sensitive system, it would behave\n> differently because \"*.TXT\" does not match \"file.txt\"?\n>\n> How do other systems address it? Your Java, Ruby, etc. sources may\n> refer to another file with \"import\" and the derivation of the file\n> names from class names or package names would have the same issue,\n> isn't it? Do they have an option that lets you say\n>\n> Even though the import statements may say \"import a.b.C\", we\n> know that the source tarball was prepared on a case insensitive\n> system, and I want you to look for a/b/C.java and a/b/c.java and\n> use what was found.\n>\n> or something like that? Same for anything that records other\n> filenames in the content to refer to them, like \"Makefile\".\n>\n> My knee jerk reaction to that is that .gitattributes and .gitignore\n> should not be instructed to go case insensitive on case sensitive\n> systems. If the system is case insensitive but case preserving,\n> it probably would make sense not to do case insensitive matching,\n> which would prevent the issue from happening in the first place.\n\nSorry, but there is a slight leap in the above that makes it hard to\ntrack my thought, so let me clarify a bit. \n\nIn the above, I am guessing the answer to the \"How do other systems\naddress it?\" question to be \"nothing\". And that leads to the\nconclusion that it is better to do \"nothing on case sensitive\nsystems, and probably become evem more strict on case insensitive\nbut case preserving systems\", because that will give us a chance to\nexpose the problem earlier, hopefully even on the originating\nsystem.\n"},{"id":"310078","messageId":"77FC347D-574E-4A4C-8114-8AD14222279B@gmail.com","threadId":"44941","inReplyTo":"xmqqwpdlr2ht.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC] Case insensitive Git attributes","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-01-24T09:49:03Z","receivedAt":"2017-01-24T09:49:12Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 23 Jan 2017, at 20:38, Junio C Hamano wrote:\n> \n> Junio C Hamano writes:\n> \n>> So you are worried about the case where somebody on a case\n>> insensitive but case preserving system would do\n>> \n>> $ edit file.txt\n>> $ edit .gitattributes\n>> $ git add file.txt .gitattributes\n>> \n>> and adds \"*.TXT\tsomeattr=true\" to the attributes file, which\n>> would set someattr to true on his system for file.txt, but when the\n>> result is checked out on a case sensitive system, it would behave\n>> differently because \"*.TXT\" does not match \"file.txt\"?\n\nCorrect!\n\n\n>> How do other systems address it? Your Java, Ruby, etc. sources may\n>> refer to another file with \"import\" and the derivation of the file\n>> names from class names or package names would have the same issue,\n>> isn't it? Do they have an option that lets you say\n>> \n>> Even though the import statements may say \"import a.b.C\", we\n>> know that the source tarball was prepared on a case insensitive\n>> system, and I want you to look for a/b/C.java and a/b/c.java and\n>> use what was found.\n>> \n>> or something like that? Same for anything that records other\n>> filenames in the content to refer to them, like \"Makefile\".\n>> \n>> My knee jerk reaction to that is that .gitattributes and .gitignore\n>> should not be instructed to go case insensitive on case sensitive\n>> systems. If the system is case insensitive but case preserving,\n>> it probably would make sense not to do case insensitive matching,\n>> which would prevent the issue from happening in the first place.\n> \n> Sorry, but there is a slight leap in the above that makes it hard to\n> track my thought, so let me clarify a bit. \n> \n> In the above, I am guessing the answer to the \"How do other systems\n> address it?\" question to be \"nothing\". And that leads to the\n> conclusion that it is better to do \"nothing on case sensitive\n> systems, and probably become evem more strict on case insensitive\n> but case preserving systems\", because that will give us a chance to\n> expose the problem earlier, hopefully even on the originating\n> system.\n\nI agree: Git attributes should behave the same on all platforms independent\nof the file system type. I dug a bit deeper and realized that this is actually\nalready the case. However, the default (?) core.ignorecase=1 config on Win/Mac\ngenerates the behavior explained above. I wonder if 6eba621 (\"attr.c: respect \ncore.ignorecase when matching attribute patterns\", 2011-10-11) was a good idea.\n\nAFAIK disabling core.ignorecase entirely on Win/Mac is no solution as this would\ngenerate other trouble.\n\nGit users can already create case insensitive gitattributes pattern. E.g.:\n*.[tT][xX][tT]\n\nHowever, based on my dayjob experience no Win/Mac developer does that as it\nmakes the gitattributes file unreadable. Consequently, Linux developers are \nscrewed. Therefore, I wonder if it would make sense to introduce a shortcut\nfor the case insensitive glob pattern. E.g.:\n\n*.txt ignorecase\n\nIf Git detects the ignorecase attribute then it could generate *.[tT][xX][tT]\nautomatically.\n\n"}]}