{"thread":{"id":"48762","subject":"Unexpected ignorecase=false behavior on Windows","startedAt":"2018-06-22T12:10:13Z","lastAt":"2018-06-25T17:38:24Z","messageCount":7,"participants":["Marc Strapetz","Johannes Sixt","Bryan Turner","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"350723","messageId":"c5abdd45-a919-96f6-8560-5fd943069f5e@syntevo.com","threadId":"48762","inReplyTo":null,"subject":"Unexpected ignorecase=false behavior on Windows","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2018-06-22T12:04:09Z","receivedAt":"2018-06-22T12:10:13Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"On Windows, when creating following repository:\n\n$ git init\n$ echo \"1\" > file.txt\n$ git add .\n$ git commit -m \"initial import\"\n$ ren file.txt File.txt\n$ git config core.ignorecase false\n\nStatus results are:\n\n$ git status --porcelain\n?? File.txt\n\nAs on Unix, I would expect to see:\n\n$ git status --porcelain\n  D file.txt\n?? File.txt\n\nIs the Windows behavior intended? I'm asking, because e.g. JGit will \nreport missing files, too, and I'm wondering what would be the correct \nway to resolve this discrepancy? (JGit does not have \n\"ignorecase=true\"-support at all, btw).\n\nTested with git version 2.17.1.windows.2\n\n-Marc\n\n\n\n\n\n\n\n\n"},{"id":"350749","messageId":"1c7e338e-157b-fd2f-5eb1-01373f627acd@kdbg.org","threadId":"48762","inReplyTo":"c5abdd45-a919-96f6-8560-5fd943069f5e@syntevo.com","subject":"Re: Unexpected ignorecase=false behavior on Windows","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2018-06-22T17:36:05Z","receivedAt":"2018-06-22T17:36:11Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 22.06.2018 um 14:04 schrieb Marc Strapetz:\n> On Windows, when creating following repository:\n> \n> $ git init\n> $ echo \"1\" > file.txt\n> $ git add .\n> $ git commit -m \"initial import\"\n> $ ren file.txt File.txt\n> $ git config core.ignorecase false\n\nThis is a user error. core.ignorecase is *not* an instruction as in \n\"hey, Git, do not ignore the case of file names\". It is better regarded \nas an internal value, with which Git remembers how it should treat the \nnames of files that it receives when it traverses the directories on the \ndisk.\n\nGit could probe the file system capabilities each time it runs. But that \nwould be wasteful. Hence, this probe happens only once when the \nrepository is initialized, and the result is recorded in this \nconfiguration value. You should not change it.\n\n> Status results are:\n> \n> $ git status --porcelain\n> ?? File.txt\n> \n> As on Unix, I would expect to see:\n> \n> $ git status --porcelain\n>   D file.txt\n> ?? File.txt\n> \n> Is the Windows behavior intended? I'm asking, because e.g. JGit will \n> report missing files, too, and I'm wondering what would be the correct \n> way to resolve this discrepancy? (JGit does not have \n> \"ignorecase=true\"-support at all, btw).\n\nThen I don't think there is a way to remove the discrepancy.\n\n-- Hannes\n"},{"id":"350759","messageId":"2cf2d884-de1a-7b9b-5aca-1f396ad205a2@syntevo.com","threadId":"48762","inReplyTo":"1c7e338e-157b-fd2f-5eb1-01373f627acd@kdbg.org","subject":"Re: Unexpected ignorecase=false behavior on Windows","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2018-06-22T20:45:46Z","receivedAt":"2018-06-22T20:45:52Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"On 22.06.2018 19:36, Johannes Sixt wrote:\n> Am 22.06.2018 um 14:04 schrieb Marc Strapetz:\n>> On Windows, when creating following repository:\n>>\n>> $ git init\n>> $ echo \"1\" > file.txt\n>> $ git add .\n>> $ git commit -m \"initial import\"\n>> $ ren file.txt File.txt\n>> $ git config core.ignorecase false\n> \n> This is a user error. core.ignorecase is *not* an instruction as in \n> \"hey, Git, do not ignore the case of file names\". It is better regarded \n> as an internal value, with which Git remembers how it should treat the \n> names of files that it receives when it traverses the directories on the \n> disk.\n> \n> Git could probe the file system capabilities each time it runs. But that \n> would be wasteful. Hence, this probe happens only once when the \n> repository is initialized, and the result is recorded in this \n> configuration value. You should not change it.\n\nSorry, it looks like my example was misleading. I'm actually questioning \ncurrent behavior in case of Windows repositories with core.ignorecase \ninitialized to false, like in following setup:\n\n$ git init\n$ git config core.ignorecase false\n\nThe repository is now set up to be case-sensitive on Windows. From this \npoint on, core.ignorecase won't change anymore and the repository will \nbe filled:\n\n$ echo \"1\" > file.txt\n$ git add .\n$ git commit -m \"initial import\"\n$ ren file.txt File.txt\n\nStill, status results are:\n\n$ git status --porcelain\n?? File.txt\n\nWith the same setup sequence on Unix, it's:\n\n$ git status --porcelain\n   D file.txt\n?? File.txt\n\nIs this difference, which is depending on the platform, intended? Why \nnot report missing file.txt as well?\n\nThe drawback of the current behavior is that a subsequent \"git add .\" \nwill result in two file names in the .git/index which are only differing \nin case. This will break the repository on Windows, because only one of \nboth files can be checked out in the working tree. Also, it makes \ncase-only renames harder to be performed.\n\n-Marc\n"},{"id":"350763","messageId":"CAGyf7-GvcN8EhMgtaZcDJNYNdfLwVH8HVBDmZqJU40nze0NSEA@mail.gmail.com","threadId":"48762","inReplyTo":"2cf2d884-de1a-7b9b-5aca-1f396ad205a2@syntevo.com","subject":"Re: Unexpected ignorecase=false behavior on Windows","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2018-06-22T20:58:57Z","receivedAt":"2018-06-22T20:59:15Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Fri, Jun 22, 2018 at 1:45 PM Marc Strapetz <marc.strapetz@syntevo.com> wrote:\n>\n> On 22.06.2018 19:36, Johannes Sixt wrote:\n> > Am 22.06.2018 um 14:04 schrieb Marc Strapetz:\n> >> On Windows, when creating following repository:\n> >>\n> >> $ git init\n> >> $ echo \"1\" > file.txt\n> >> $ git add .\n> >> $ git commit -m \"initial import\"\n> >> $ ren file.txt File.txt\n> >> $ git config core.ignorecase false\n> >\n> > This is a user error. core.ignorecase is *not* an instruction as in\n> > \"hey, Git, do not ignore the case of file names\". It is better regarded\n> > as an internal value, with which Git remembers how it should treat the\n> > names of files that it receives when it traverses the directories on the\n> > disk.\n> >\n> > Git could probe the file system capabilities each time it runs. But that\n> > would be wasteful. Hence, this probe happens only once when the\n> > repository is initialized, and the result is recorded in this\n> > configuration value. You should not change it.\n>\n> Sorry, it looks like my example was misleading. I'm actually questioning\n> current behavior in case of Windows repositories with core.ignorecase\n> initialized to false, like in following setup:\n>\n> $ git init\n> $ git config core.ignorecase false\n>\n> The repository is now set up to be case-sensitive on Windows. From this\n> point on, core.ignorecase won't change anymore and the repository will\n> be filled:\n\nI don't think Hannes's point was _when_ you changed it; it was that\nyou changed it _at all_.\n\nGit on Windows is not designed to run with anything other than\ncore.ignoreCase=true, and attempting to do so will cause unexpected\nbehavior. In other words, it's not a behavior toggle so user's can\nrequest the functionality to work one way or the other; it's an\nimplementation detail that `git init` and `git clone` set when a\nrepository is created purely so they don't have to probe the file\nsystem each time you run a `git` command.\n\nNTFS is case-preserving-but-case-insensitive by default[1]. So long as\nthat's the case, the only mode for running Git on Windows is\ncore.ignoreCase=true.\n\nHopefully this clarifies things!\n\nBryan\n\n[1] Windows 10 1803 introduced the ability to set a folder as\ncase-sensitive[2], but, since it's not inherited automatically by\nsubdirectories, it still doesn't work well for Git.\n[2] https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/\n\n>\n> $ echo \"1\" > file.txt\n> $ git add .\n> $ git commit -m \"initial import\"\n> $ ren file.txt File.txt\n>\n> Still, status results are:\n>\n> $ git status --porcelain\n> ?? File.txt\n>\n> With the same setup sequence on Unix, it's:\n>\n> $ git status --porcelain\n>    D file.txt\n> ?? File.txt\n>\n> Is this difference, which is depending on the platform, intended? Why\n> not report missing file.txt as well?\n>\n> The drawback of the current behavior is that a subsequent \"git add .\"\n> will result in two file names in the .git/index which are only differing\n> in case. This will break the repository on Windows, because only one of\n> both files can be checked out in the working tree. Also, it makes\n> case-only renames harder to be performed.\n>\n> -Marc\n"},{"id":"350795","messageId":"c9a9167c-8528-c85a-e7aa-9197ab92e685@syntevo.com","threadId":"48762","inReplyTo":"CAGyf7-GvcN8EhMgtaZcDJNYNdfLwVH8HVBDmZqJU40nze0NSEA@mail.gmail.com","subject":"Re: Unexpected ignorecase=false behavior on Windows","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2018-06-24T10:07:32Z","receivedAt":"2018-06-24T10:07:45Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"On 22.06.2018 22:58, Bryan Turner wrote:\n> On Fri, Jun 22, 2018 at 1:45 PM Marc Strapetz <marc.strapetz@syntevo.com> wrote:\n>>\n>> On 22.06.2018 19:36, Johannes Sixt wrote:\n>>> Am 22.06.2018 um 14:04 schrieb Marc Strapetz:\n>>>> On Windows, when creating following repository:\n>>>>\n>>>> $ git init\n>>>> $ echo \"1\" > file.txt\n>>>> $ git add .\n>>>> $ git commit -m \"initial import\"\n>>>> $ ren file.txt File.txt\n>>>> $ git config core.ignorecase false\n>>>\n>>> This is a user error. core.ignorecase is *not* an instruction as in\n>>> \"hey, Git, do not ignore the case of file names\". It is better regarded\n>>> as an internal value, with which Git remembers how it should treat the\n>>> names of files that it receives when it traverses the directories on the\n>>> disk.\n>>>\n>>> Git could probe the file system capabilities each time it runs. But that\n>>> would be wasteful. Hence, this probe happens only once when the\n>>> repository is initialized, and the result is recorded in this\n>>> configuration value. You should not change it.\n>>\n>> Sorry, it looks like my example was misleading. I'm actually questioning\n>> current behavior in case of Windows repositories with core.ignorecase\n>> initialized to false, like in following setup:\n>>\n>> $ git init\n>> $ git config core.ignorecase false\n>>\n>> The repository is now set up to be case-sensitive on Windows. From this\n>> point on, core.ignorecase won't change anymore and the repository will\n>> be filled:\n> \n> I don't think Hannes's point was _when_ you changed it; it was that\n> you changed it _at all_.\n> \n> Git on Windows is not designed to run with anything other than\n> core.ignoreCase=true, and attempting to do so will cause unexpected\n> behavior. In other words, it's not a behavior toggle so user's can\n> request the functionality to work one way or the other; it's an\n> implementation detail that `git init` and `git clone` set when a\n> repository is created purely so they don't have to probe the file\n> system each time you run a `git` command.\n> \n> NTFS is case-preserving-but-case-insensitive by default[1]. So long as\n> that's the case, the only mode for running Git on Windows is\n> core.ignoreCase=true.\n> \n> Hopefully this clarifies things!\n\nThanks, it does. In this case, I'd suggest to make this clear in the \ndocumentation, too. I've just sent a patch.\n\n-Marc\n"},{"id":"350848","messageId":"xmqqfu1aq0ya.fsf@gitster-ct.c.googlers.com","threadId":"48762","inReplyTo":"CAGyf7-GvcN8EhMgtaZcDJNYNdfLwVH8HVBDmZqJU40nze0NSEA@mail.gmail.com","subject":"Re: Unexpected ignorecase=false behavior on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-06-25T16:34:53Z","receivedAt":"2018-06-25T16:34:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bryan Turner <bturner@atlassian.com> writes:\n\n> Git on Windows is not designed to run with anything other than\n> core.ignoreCase=true, and attempting to do so will cause unexpected\n> behavior.\n\nEven though I fully agree with your conclusion that the document\nmust make it crystal clear that core.ignoreCase must be set to\nreflect the reality, I found the above statement misleading and do\nnot want it to be used as the basis of a documentation update.  But\nit is possible that I am misunderstanding the current state of\naffairs.\n\nIs the case insensitivity that deeply ingrained in the Git for\nWindows code?\n\nIOW, even if the code used to build Git for Windows were executed on\na case sensitive filesystem, is there a case-smashing code on _our_\nside that kicks in to cause unexpected behaviour, _even_ when\ncore.ignorecase is set to false to match (hypothetical) reality?\n\nTo put it yet another way, if a case sensitive filesystem were\navailable, wouldn't running \"git init\" from Git for Windows in a\ndirectory on such a filesytem set core.ignoreCase to false in the\nresulting repository and from then on wouldn't everything work fine?\n\nIf my suspicion (i.e. the code for Git for Windows is perfectly\nfine---it is just the users are not running with case sensitive\nfilesystems and flipping core.ignoreCase to true does not make case\nincapable filesystems suddenly capable) is correct, then it is not\n\"Git on Windows is not designed to run\" from two angles.  (1) it is\nnot just Git for Windows---Git running on UNIX that mounts VFAT, or\nGit running on macOS with default HFS+, would exhibit the same\nsymptom, and (2) it is not \"Git is not designed to run\"---it is\ncore.ignoreCase that is not designed to be a way to make case\nincapable filesystems suddenly capable of distinguishing cases in\nfilesystems.\n\nThanks.\n"},{"id":"350866","messageId":"CAGyf7-GeE8jRGPkME9rHKPtHEQ6P1+ebpMMWAtMh01uO3bfy8w@mail.gmail.com","threadId":"48762","inReplyTo":"xmqqfu1aq0ya.fsf@gitster-ct.c.googlers.com","subject":"Re: Unexpected ignorecase=false behavior on Windows","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2018-06-25T17:38:07Z","receivedAt":"2018-06-25T17:38:24Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Mon, Jun 25, 2018 at 9:34 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Bryan Turner <bturner@atlassian.com> writes:\n>\n> > Git on Windows is not designed to run with anything other than\n> > core.ignoreCase=true, and attempting to do so will cause unexpected\n> > behavior.\n>\n> Even though I fully agree with your conclusion that the document\n> must make it crystal clear that core.ignoreCase must be set to\n> reflect the reality, I found the above statement misleading and do\n> not want it to be used as the basis of a documentation update.  But\n> it is possible that I am misunderstanding the current state of\n> affairs.\n>\n> Is the case insensitivity that deeply ingrained in the Git for\n> Windows code?\n>\n> IOW, even if the code used to build Git for Windows were executed on\n> a case sensitive filesystem, is there a case-smashing code on _our_\n> side that kicks in to cause unexpected behaviour, _even_ when\n> core.ignorecase is set to false to match (hypothetical) reality?\n>\n> To put it yet another way, if a case sensitive filesystem were\n> available, wouldn't running \"git init\" from Git for Windows in a\n> directory on such a filesytem set core.ignoreCase to false in the\n> resulting repository and from then on wouldn't everything work fine?\n>\n> If my suspicion (i.e. the code for Git for Windows is perfectly\n> fine---it is just the users are not running with case sensitive\n> filesystems and flipping core.ignoreCase to true does not make case\n> incapable filesystems suddenly capable) is correct, then it is not\n> \"Git on Windows is not designed to run\" from two angles.  (1) it is\n> not just Git for Windows---Git running on UNIX that mounts VFAT, or\n> Git running on macOS with default HFS+, would exhibit the same\n> symptom, and (2) it is not \"Git is not designed to run\"---it is\n> core.ignoreCase that is not designed to be a way to make case\n> incapable filesystems suddenly capable of distinguishing cases in\n> filesystems.\n\nApologies for the unclear word choice. Given Git was designed first to\nwork with case-sensitive filesystems, certainly the obvious (and\ncorrect) conclusion is that Git itself is fine in a case-sensitive\nenvironment. It wasn't my intention to suggest otherwise.\n\nNote that my word choice was not \"Git _for_ Windows\", however; it was\n\"Git _on_ Windows\". (This still doesn't change the correctness of your\nclarification, let me be quick to add. I'm only pointing it out\nbecause it's relevant to what I intended the comment to say.) On\nWindows, the default filesystem is NTFS, and NTFS is not case\nsensitive. Hence, Git on Windows (by which I'm implying Git on NTFS),\nis not designed to run with anything other than core.ignoreCase=true,\nbecause that setting aligns Git's expectations with how the underlying\nfilesystem actually works. In other words, Git on a case-insensitive\nfilesystem (APFS, HFS+, FAT32, exFAT, vFAT, NTFS, etc.) is not\ndesigned to be run with anything other than core.ignoreCase=true.\n\nBryan\n\n>\n> Thanks.\n"}]}