{"thread":{"id":"30020","subject":"[PATCH] Demonstrate failure of 'core.ignorecase = true'","startedAt":"2012-03-21T22:50:22Z","lastAt":"2012-03-23T18:57:43Z","messageCount":23,"participants":["Peter J. Weisberg","Junio C Hamano","Johannes Sixt","Zbigniew Jędrzejewski-Szmek","Jeff King","PJ Weisberg","Thomas Rast"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"187441","messageId":"1332370222-5123-1-git-send-email-pj@irregularexpressions.net","threadId":"30020","inReplyTo":null,"subject":"[PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Peter J. Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-03-21T22:50:22Z","receivedAt":"2012-03-21T22:50:22Z","isPatch":true,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"From: \"Peter J. Weisberg\" \n\nOn a filesystem that *is* case-sensitive, renaming a file to a name\nthat would be equivalent on a case-insensitive filesystem makes Git\nthink the original file was deleted. Add a test that demonstrates\nthis as a known error.\n---\nI have a repository that contains files that I sync from a place where\nnames are case-insensitive. When I sync a file that has a change in\nthe case of the file name, I want Git to ignore that non-change. I\nwould think core.ignorecase would accomplish this, but it does not.\n---\n t/t2000-ignorecase-config.sh | 21 +++++++++++++++++++++\n 1 files changed, 21 insertions(+), 0 deletions(-)\n create mode 100755 t/t2000-ignorecase-config.sh\n\ndiff --git a/t/t2000-ignorecase-config.sh b/t/t2000-ignorecase-config.sh\nnew file mode 100755\nindex 0000000..9d05cee\n--- /dev/null\n+++ b/t/t2000-ignorecase-config.sh\n@@ -0,0 +1,21 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2012 Peter J Weisberg\n+#\n+\n+test_description='core.ignorecase'\n+\n+. ./test-lib.sh\n+\n+test_expect_failure \"diff-files doesn't show case change when ignorecase=true\" '\n+\tgit config core.ignorecase true &&\n+\n+\ttouch foo &&\n+\tgit add foo &&\n+\tgit commit -m \"foo\" &&\n+\tmv foo FOO &&\n+\n+\ttest -z \"$(git diff-files)\"\n+'\n+\n+test_done\n-- \n1.7.9.1\n"},{"id":"187442","messageId":"7vmx79zeui.fsf@alter.siamese.dyndns.org","threadId":"30020","inReplyTo":"1332370222-5123-1-git-send-email-pj@irregularexpressions.net","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-21T23:58:13Z","receivedAt":"2012-03-21T23:58:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Peter J. Weisberg\" writes:\n\n> From: \"Peter J. Weisberg\" \n>\n> On a filesystem that *is* case-sensitive, renaming a file to a name\n> that would be equivalent on a case-insensitive filesystem makes Git\n> think the original file was deleted. Add a test that demonstrates\n> this as a known error.\n> ---\n\nThanks, Needs sign-off.\n\n> I have a repository that contains files that I sync from a place where\n> names are case-insensitive. When I sync a file that has a change in\n> the case of the file name, I want Git to ignore that non-change. I\n> would think core.ignorecase would accomplish this, but it does not.\n> ---\n\nNo need for the second \"---\"\n\n> t/t2000-ignorecase-config.sh | 21 +++++++++++++++++++++\n\nWe'd rather not waste a new test number for a single test like this.\n\n> 1 files changed, 21 insertions(+), 0 deletions(-)\n> create mode 100755 t/t2000-ignorecase-config.sh\n>\n> diff --git a/t/t2000-ignorecase-config.sh b/t/t2000-ignorecase-config.sh\n> new file mode 100755\n> index 0000000..9d05cee\n> --- /dev/null\n> +++ b/t/t2000-ignorecase-config.sh\n> @@ -0,0 +1,21 @@\n> +#!/bin/sh\n> +#\n> +# Copyright (c) 2012 Peter J Weisberg\n> +#\n> +\n> +test_description='core.ignorecase'\n> +\n> +. ./test-lib.sh\n> +\n> +test_expect_failure \"diff-files doesn't show case change when ignorecase=true\" '\n\nThis needs to be protected by test prerequisite to make sure that the test\nis run on a case insensitive filesystem. Even if you declare that the\nfilesystem is case insensitive by setting core.ignorecase to true, the\nunderlying system calls like open(\"foo\") will *not* magically start\nreturning a file descriptor opened for \"FOO\" if your filesystem is not\ncase insensitive.\n\nPerhaps something as simple as the following would do:\n\n\t# on case insensitive filesystems, \"mv\" would fail\n if >testfile && ! mv testfile TESTFILE >/dev/null 2>/dev/null\n then\n test_set_prereq CASE_INSENSITIVE_FS\n fi\n rm -f testfile TESTFILE\n\n\ttest_expect_failure CASE_INSENSITIVE_FS \"diff-files doesn't...\" '\n \t... test body comes here ...\n\n\n> +\tgit config core.ignorecase true &&\n> +\n> +\ttouch foo &&\n> +\tgit add foo &&\n> +\tgit commit -m \"foo\" &&\n> +\tmv foo FOO &&\n> +\n> +\ttest -z \"$(git diff-files)\"\n> +'\n> +\n> +test_done\n"},{"id":"187448","messageId":"4F6ACB67.1080503@viscovery.net","threadId":"30020","inReplyTo":"1332370222-5123-1-git-send-email-pj@irregularexpressions.net","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-03-22T06:49:11Z","receivedAt":"2012-03-22T06:49:11Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 3/21/2012 23:50, schrieb Peter J. Weisberg:\n> +test_expect_failure \"diff-files doesn't show case change when ignorecase=true\" '\n> +\tgit config core.ignorecase true &&\n> +\n> +\ttouch foo &&\n> +\tgit add foo &&\n> +\tgit commit -m \"foo\" &&\n> +\tmv foo FOO &&\n> +\n> +\ttest -z \"$(git diff-files)\"\n> +'\n\nI tried this in my git.git clone on Windows (NTFS), and it did not produce\nthe expected failure:\n\nD:\\Src\\mingw-git>git config core.ignorecase\ntrue\n\nD:\\Src\\mingw-git>mv git.c GIT.C\n\nD:\\Src\\mingw-git>git diff-files\n\nD:\\Src\\mingw-git>echo %ERRORLEVEL%\n0\n\nD:\\Src\\mingw-git>ls -l [Gg][Ii][Tt].[Cc]\n-rw-r--r-- 1 jsixt Administ 17166 Mar 22 06:44 GIT.C\n\nWhat am I missing?\n\n-- Hannes\n"},{"id":"187456","messageId":"4F6B0C3E.8090501@in.waw.pl","threadId":"30020","inReplyTo":"4F6ACB67.1080503@viscovery.net","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Zbigniew Jędrzejewski-Szmek","fromEmail":"zbyszek@in.waw.pl","sentAt":"2012-03-22T11:25:50Z","receivedAt":"2012-03-22T11:25:50Z","isPatch":true,"sender":{"key":"zbyszek@in.waw.pl","avatar":"https://avatars.githubusercontent.com/u/349618?v=4"},"body":"On 03/22/2012 07:49 AM, Johannes Sixt wrote:\n> Am 3/21/2012 23:50, schrieb Peter J. Weisberg:\n>> +test_expect_failure \"diff-files doesn't show case change when ignorecase=true\" '\n>> +\tgit config core.ignorecase true&&\n>> +\n>> +\ttouch foo&&\n>> +\tgit add foo&&\n>> +\tgit commit -m \"foo\"&&\n>> +\tmv foo FOO&&\n>> +\n>> +\ttest -z \"$(git diff-files)\"\n>> +'\n>\n> I tried this in my git.git clone on Windows (NTFS), and it did not produce\n> the expected failure:\n...\n> What am I missing?\n\nThe OP meant a case-sensitive fs, not an insensitive one.\n\"On a filesystem that *is* case-sensitive, ...\"\n\nThis is a question about core.ignorecase=true. The description in \ngit-config(1) is so vague, that it's hard to say what behaviour is expected.\n\nZbyszek\n"},{"id":"187470","messageId":"20120322141245.GB8803@sigill.intra.peff.net","threadId":"30020","inReplyTo":"4F6B0C3E.8090501@in.waw.pl","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-22T14:12:45Z","receivedAt":"2012-03-22T14:12:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 22, 2012 at 12:25:50PM +0100, Zbigniew Jędrzejewski-Szmek wrote:\n\n> >What am I missing?\n> \n> The OP meant a case-sensitive fs, not an insensitive one.\n> \"On a filesystem that *is* case-sensitive, ...\"\n> \n> This is a question about core.ignorecase=true. The description in\n> git-config(1) is so vague, that it's hard to say what behaviour is\n> expected.\n\nI don't know. It says:\n\n If true, this option enables various workarounds to enable git to work\n better on filesystems that are not case sensitive, like FAT. For\n example, if a directory listing finds \"makefile\" when git expects\n \"Makefile\", git will assume it is really the same file, and continue\n to remember it as \"Makefile\".\n\nwhich seems pretty clear to me that this is \"let git work better on\ncase-insensitive filesystems\", not \"make git magically case-insensitive\non case sensitive filesystem\". But maybe we could add be more explicit,\nlike:\n\n-- >8 --\nSubject: docs: clarify core.ignorecase on case-sensitive filesystems\n\ncore.ignorecase is about handling case-insensitive\nfilesystems, not making git magically case-insensitive on a\ncase-sensitive filesystem. That's implied by the current\ntext, but let's add an explicit note.\n\nSigned-off-by: Jeff King \n---\n Documentation/config.txt | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex c081657..abbab91 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -191,6 +191,10 @@ core.ignorecase::\n The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]\n will probe and set core.ignorecase true if appropriate when the repository\n is created.\n++\n+Note that this is about making git work well on a case-insensitive\n+filesystem. It will not make git case-insensitive when used on a\n+case-sensitive filesystem.\n \n core.trustctime::\n \tIf false, the ctime differences between the index and the\n-- \n1.7.10.rc0.9.gdcbe9\n"},{"id":"187475","messageId":"7vbonozi8c.fsf@alter.siamese.dyndns.org","threadId":"30020","inReplyTo":"20120322141245.GB8803@sigill.intra.peff.net","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-22T16:57:23Z","receivedAt":"2012-03-22T16:57:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I don't know. It says:\n>\n> If true, this option enables various workarounds to enable git to work\n> better on filesystems that are not case sensitive, like FAT. For\n> example, if a directory listing finds \"makefile\" when git expects\n> \"Makefile\", git will assume it is really the same file, and continue\n> to remember it as \"Makefile\".\n>\n> which seems pretty clear to me that this is \"let git work better on\n> case-insensitive filesystems\", not \"make git magically case-insensitive\n> on case sensitive filesystem\".\n\nYes, it says what it needs to say quite clearly.\n\n> But maybe we could add be more explicit,\n> like:\n\nHrm, replacing unclear part with clarified text may make sense, but it\nwould not help adding new text if the existing description is not clear\nenough.\n\nHow about doing it like this?\n\n Case-insensitive filesystems like FAT and HFS+ have various strange\n behaviours, like reporting that a file \"Makefile\" already exists when\n the file that actually exists on them is \"makefile\". By setting this\n variable to `true`, Git employs logic to work around them.\n\n The default is false, except that git-clone[1] and git-init[1] will\n probe the filesystem and set it to `true` as necessary when a new\n repository is created.\n"},{"id":"187480","messageId":"20120322173701.GA11928@sigill.intra.peff.net","threadId":"30020","inReplyTo":"7vbonozi8c.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-22T17:37:01Z","receivedAt":"2012-03-22T17:37:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 22, 2012 at 09:57:23AM -0700, Junio C Hamano wrote:\n\n> Hrm, replacing unclear part with clarified text may make sense, but it\n> would not help adding new text if the existing description is not clear\n> enough.\n> \n> How about doing it like this?\n> \n> Case-insensitive filesystems like FAT and HFS+ have various strange\n> behaviours, like reporting that a file \"Makefile\" already exists when\n> the file that actually exists on them is \"makefile\". By setting this\n> variable to `true`, Git employs logic to work around them.\n> \n> The default is false, except that git-clone[1] and git-init[1] will\n> probe the filesystem and set it to `true` as necessary when a new\n> repository is created.\n\nIMHO, it suffers from the same problem as the original, which is that it\ndoes tells when to use core.ignorecase, but does not specify what\nhappens when one sets core.ignorecase to true on a case-sensitive\nfilesystem. Maybe we should be more explicit about what _does_ happen in\nthat case (to be honest, I am not completely sure). Or just say that it\nis not a supported use case.\n\n-Peff\n"},{"id":"187490","messageId":"7viphwxyp1.fsf@alter.siamese.dyndns.org","threadId":"30020","inReplyTo":"20120322173701.GA11928@sigill.intra.peff.net","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-22T18:44:42Z","receivedAt":"2012-03-22T18:44:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Mar 22, 2012 at 09:57:23AM -0700, Junio C Hamano wrote:\n>\n>> Hrm, replacing unclear part with clarified text may make sense, but it\n>> would not help adding new text if the existing description is not clear\n>> enough.\n>> \n>> How about doing it like this?\n>> \n>> Case-insensitive filesystems like FAT and HFS+ have various strange\n>> behaviours, like reporting that a file \"Makefile\" already exists when\n>> the file that actually exists on them is \"makefile\". By setting this\n>> variable to `true`, Git employs logic to work around them.\n>> \n>> The default is false, except that git-clone[1] and git-init[1] will\n>> probe the filesystem and set it to `true` as necessary when a new\n>> repository is created.\n>\n> IMHO, it suffers from the same problem as the original, which is that it\n> does tells when to use core.ignorecase, but does not specify what\n\nI wanted it to tell *what* happens when core.ignorecase is set. In other\nwords, I wanted the description to say that the logic employed is to work\naround what case-insensitive filesystems do. Case sensitive filesystems\nobviously do not do what case-insensitive ones do (like reporting a\n\"Makefile\" exists when only \"makefile\" exists), so I hoped that it was\nclear enough that the additional logic would not be suitable there.\n\n> happens when one sets core.ignorecase to true on a case-sensitive\n> filesystem. Maybe we should be more explicit about what _does_ happen in\n> that case (to be honest, I am not completely sure). Or just say that it\n> is not a supported use case.\n\nI guess we really need to make the description foolproof then.\n\n ... exists on them is \"makefile\". By setting this\n\tvariable to `true`, Git employs logic to work around them.\n Setting this to `true` on a case insensitive filesystem does\n\tnot make any sense, because it would not magically make your\n\tsystem to treat your filesystem case insensitively.\n"},{"id":"187501","messageId":"20120322190705.GB27037@sigill.intra.peff.net","threadId":"30020","inReplyTo":"7viphwxyp1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-22T19:07:05Z","receivedAt":"2012-03-22T19:07:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 22, 2012 at 11:44:42AM -0700, Junio C Hamano wrote:\n\n> I wanted it to tell *what* happens when core.ignorecase is set. In other\n> words, I wanted the description to say that the logic employed is to work\n> around what case-insensitive filesystems do. Case sensitive filesystems\n> obviously do not do what case-insensitive ones do (like reporting a\n> \"Makefile\" exists when only \"makefile\" exists), so I hoped that it was\n> clear enough that the additional logic would not be suitable there.\n\nAh. I see now why you made the change you did. But if I missed it,\nperhaps it was too subtle (of course, I found the other one perfectly\nadequate, so...).\n\n> I guess we really need to make the description foolproof then.\n> \n> ... exists on them is \"makefile\". By setting this\n> \tvariable to `true`, Git employs logic to work around them.\n> Setting this to `true` on a case insensitive filesystem does\n> \tnot make any sense, because it would not magically make your\n> \tsystem to treat your filesystem case insensitively.\n\nI'm OK with that (modulo s/insensitive/sensitive/ on the third line).\nIt may be overly explicit, but I would rather err on that side.\n\n-Peff\n"},{"id":"187520","messageId":"4F6B84DF.8040806@in.waw.pl","threadId":"30020","inReplyTo":"7viphwxyp1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Zbigniew Jędrzejewski-Szmek","fromEmail":"zbyszek@in.waw.pl","sentAt":"2012-03-22T20:00:31Z","receivedAt":"2012-03-22T20:00:31Z","isPatch":true,"sender":{"key":"zbyszek@in.waw.pl","avatar":"https://avatars.githubusercontent.com/u/349618?v=4"},"body":"On 03/22/2012 07:44 PM, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>> On Thu, Mar 22, 2012 at 09:57:23AM -0700, Junio C Hamano wrote:\n>>\n>>> Hrm, replacing unclear part with clarified text may make sense, but it\n>>> would not help adding new text if the existing description is not clear\n>>> enough.\n>>>\n>>> How about doing it like this?\n>>>\n>>> Case-insensitive filesystems like FAT and HFS+ have various strange\n>>> behaviours, like reporting that a file \"Makefile\" already exists when\n>>> the file that actually exists on them is \"makefile\". By setting this\n>>> variable to `true`, Git employs logic to work around them.\nI think that this paragraph is too judgemental. While case-insensitive \nfilesystems may be a pain, they are not \"strange\" to their users, but \nrather natural, and don't require \"working around\".\n\n> I guess we really need to make the description foolproof then.\n>\n> ... exists on them is \"makefile\". By setting this\n> \tvariable to `true`, Git employs logic to work around them.\n> Setting this to `true` on a case insensitive filesystem does\n> \tnot make any sense, because it would not magically make your\n> \tsystem to treat your filesystem case insensitively.\nEven this updated text does not say _what_ happens when core.ignorecase \nis set on a case-insensitive filesystem. Once that's cleared up, then \nthe corner case of core.ignorecase=true on case-sensitive fs can be tackled.\n\nMaybe:\n--- 8< ---\nWhen set, case-insensitive comparisons will be used when internally \ncomparing file names.\n\nThe default is false, but when a new repository is created by \ngit-clone[1] or git-init[1], git will probe the filesystem and set it to \n`true` if the filesystem is case-insensitive.\n\nOn case-insensitive filesystems like FAT, NTFS and HSF+, names that \ndiffer only in capitalization, like \"Makefile\" and \"makefile\", refer to \nthe same file. While such filesystems usually preserve the \ncapitalization used during file creation, tools designed for such \nfilesystems will often modify capitalization when saving files and when \ndisplaying filenames. Enabling core.ignorecase causes git to ignore \ncase-only differences in file names.\n\nEnabling core.ignorecase on a case insensitive filesystem does\nnot make sense, because filenames with different capitalization will \nstill be treated as different by the filesystem.\n--- >8 ---\n\n[+cc Brandon Casey]\n\nzByszek\n"},{"id":"187523","messageId":"7vobrowf36.fsf@alter.siamese.dyndns.org","threadId":"30020","inReplyTo":"20120322190705.GB27037@sigill.intra.peff.net","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-22T20:33:33Z","receivedAt":"2012-03-22T20:33:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Mar 22, 2012 at 11:44:42AM -0700, Junio C Hamano wrote:\n>\n>> I wanted it to tell *what* happens when core.ignorecase is set. In other\n>> words, I wanted the description to say that the logic employed is to work\n>> around what case-insensitive filesystems do. Case sensitive filesystems\n>> obviously do not do what case-insensitive ones do (like reporting a\n>> \"Makefile\" exists when only \"makefile\" exists), so I hoped that it was\n>> clear enough that the additional logic would not be suitable there.\n>\n> Ah. I see now why you made the change you did. But if I missed it,\n> perhaps it was too subtle (of course, I found the other one perfectly\n> adequate, so...).\n>\n>> I guess we really need to make the description foolproof then.\n>> \n>> ... exists on them is \"makefile\". By setting this\n>> \tvariable to `true`, Git employs logic to work around them.\n>> Setting this to `true` on a case insensitive filesystem does\n>> \tnot make any sense, because it would not magically make your\n>> \tsystem to treat your filesystem case insensitively.\n>\n> I'm OK with that (modulo s/insensitive/sensitive/ on the third line).\n> It may be overly explicit, but I would rather err on that side.\n\nThanks for catching the typo.\n"},{"id":"187524","messageId":"7vk42cwew5.fsf@alter.siamese.dyndns.org","threadId":"30020","inReplyTo":"4F6B84DF.8040806@in.waw.pl","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-22T20:37:46Z","receivedAt":"2012-03-22T20:37:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Zbigniew Jędrzejewski-Szmek writes:\n\n> Even this updated text does not say _what_ happens when\n> core.ignorecase is set on a case-insensitive filesystem.\n\nThat was very much on purpose. We tell users not to do that, because it is\ncalling for an undefined behaviour. And leaving it undefined gives us a\nwiggle room to later do something better if we choose to.\n\n> Maybe:\n> --- 8< ---\n> When set, case-insensitive comparisons will be used when internally\n> comparing file names.\n\nWhen we try to create a new file with open(\"./Makefile\", O_CREAT) system\ncall, we do not opendir(\".\") and readdir() to see if \"makefile\" exists\nourselves at all, but the above makes it sound as if we would do such\nthings to make sure we compare filenames ignoring there case.\n\nThat is *not* what happens, and that is not what we want to say in the\ndocumentation.\n"},{"id":"187525","messageId":"CAJsNXT=YEida53nV7kj6a3cw2GibYJab4n2PucNO6inUR3HPRQ@mail.gmail.com","threadId":"30020","inReplyTo":"7vmx79zeui.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-03-22T20:40:50Z","receivedAt":"2012-03-22T20:40:50Z","isPatch":true,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"As you've probably deduced, I simply failed to RTFM. I'm not sure\nyou'll gain much by changing the description on the man page, since I\nthought the name 'ignorecase' was self-explanatory and barely even\nlooked at it. :-/\n\nOn Wed, Mar 21, 2012 at 4:58 PM, Junio C Hamano wrote:\n\n> underlying system calls like open(\"foo\") will *not* magically start\n> returning a file descriptor opened for \"FOO\" if your filesystem is not\n> case insensitive.\n\nNo, but magic_open(\"foo\") might, if someone had put forth the effort\nto write a function called magic_open. But the more I think about it,\nthe more it seems that doing everything you would need to do to make\nignorecase work the way I thought it did is almost certainly not worth\nthe effort.\n\n\n-PJ\n\nGehm's Corollary to Clark's Law: Any technology distinguishable from\nmagic is insufficiently advanced.\n"},{"id":"187527","messageId":"4F6B9160.1040300@in.waw.pl","threadId":"30020","inReplyTo":"7vk42cwew5.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Zbigniew Jędrzejewski-Szmek","fromEmail":"zbyszek@in.waw.pl","sentAt":"2012-03-22T20:53:52Z","receivedAt":"2012-03-22T20:53:52Z","isPatch":true,"sender":{"key":"zbyszek@in.waw.pl","avatar":"https://avatars.githubusercontent.com/u/349618?v=4"},"body":"On 03/22/2012 09:37 PM, Junio C Hamano wrote:\n> Zbigniew Jędrzejewski-Szmek writes:\n>\n>> Even this updated text does not say _what_ happens when\n>> core.ignorecase is set on a case-insensitive filesystem.\n>\n> That was very much on purpose. We tell users not to do that, because it is\n> calling for an undefined behaviour. And leaving it undefined gives us a\n> wiggle room to later do something better if we choose to.\n>\n>> Maybe:\n>> --- 8< ---\n>> When set, case-insensitive comparisons will be used when internally\n>> comparing file names.\n>\n> When we try to create a new file with open(\"./Makefile\", O_CREAT) system\n> call, we do not opendir(\".\") and readdir() to see if \"makefile\" exists\n> ourselves at all, but the above makes it sound as if we would do such\n> things to make sure we compare filenames ignoring there case.\n\nHence \"internally\" -- in the sense that filesystem calls are executed\nby the OS, so they can be said to be external to git. Maybe this could\nbe worded differently.\n\n> That is *not* what happens, and that is not what we want to say in the\n> documentation.\nYeah, but we should say *something*, to let the reader understand\nthe behaviour.\n\nFor example, the reader should understand, that \"work arounds\" \nimplemented by git do not include the normalization of filenames,\nand if files are added with bad capitalization, they will stay that way \non case sensitive filesystems.\n\n-\nZbyszek\n"},{"id":"187528","messageId":"CAJsNXTkEDr_bg3tCo-OOOzAe_5AVgoGV_9b0b3GOREzPE4Pg_Q@mail.gmail.com","threadId":"30020","inReplyTo":"7vk42cwew5.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-03-22T20:55:02Z","receivedAt":"2012-03-22T20:55:02Z","isPatch":true,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"2012/3/22 Junio C Hamano :\n> Zbigniew Jędrzejewski-Szmek   writes:\n>\n>> Even this updated text does not say _what_ happens when\n>> core.ignorecase is set on a case-insensitive filesystem.\n>\n> That was very much on purpose. We tell users not to do that, because it is\n> calling for an undefined behaviour. And leaving it undefined gives us a\n> wiggle room to later do something better if we choose to.\n\nWhere do you tell users not to do that? Nothing on the man page\nactually says that the behavior is undefined, but it does seem to be\nweird. Rename default.asp to Default.asp, and Git reports that\ndefault.asp was deleted, but doesn't mention Default.asp. (Presumably\nit sees Default.asp and decides that it's the same as default.asp,\nwhich it already determined was deleted. Like I said, weird.)\n\n-PJ\n\nGehm's Corollary to Clark's Law: Any technology distinguishable from\nmagic is insufficiently advanced.\n"},{"id":"187529","messageId":"7v8viswdho.fsf@alter.siamese.dyndns.org","threadId":"30020","inReplyTo":"CAJsNXT=YEida53nV7kj6a3cw2GibYJab4n2PucNO6inUR3HPRQ@mail.gmail.com","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-22T21:08:03Z","receivedAt":"2012-03-22T21:08:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"PJ Weisberg writes:\n\n> On Wed, Mar 21, 2012 at 4:58 PM, Junio C Hamano wrote:\n>\n>> underlying system calls like open(\"foo\") will *not* magically start\n>> returning a file descriptor opened for \"FOO\" if your filesystem is not\n>> case insensitive.\n>\n> No, but magic_open(\"foo\") might, if someone had put forth the effort\n> to write a function called magic_open.\n\nExactly.\n\nThat is why we avoid describing what happens when you set it on a case\nsensitive filesystem, to leave the door open for such a cleverness.\n\nIt may still be a mistake in the manual that we did not explicitly say\nthat setting core.ignorecase on a case sensitive system will give you an\nundefined behaviour.\n"},{"id":"187530","messageId":"7v4ntgwdft.fsf@alter.siamese.dyndns.org","threadId":"30020","inReplyTo":"CAJsNXTkEDr_bg3tCo-OOOzAe_5AVgoGV_9b0b3GOREzPE4Pg_Q@mail.gmail.com","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-22T21:09:10Z","receivedAt":"2012-03-22T21:09:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"PJ Weisberg writes:\n\n> 2012/3/22 Junio C Hamano :\n>> Zbigniew Jędrzejewski-Szmek   writes:\n>>\n>>> Even this updated text does not say _what_ happens when\n>>> core.ignorecase is set on a case-insensitive filesystem.\n>>\n>> That was very much on purpose. We tell users not to do that, because it is\n>> calling for an undefined behaviour. And leaving it undefined gives us a\n>> wiggle room to later do something better if we choose to.\n>\n> Where do you tell users not to do that? Nothing on the man page\n> actually says that the behavior is undefined,...\n\nRead the messages in the thread you are responding to. It is a discussion\nabout how we update the documentation to say it.\n"},{"id":"187539","messageId":"20120322230056.GC14874@sigill.intra.peff.net","threadId":"30020","inReplyTo":"4F6B84DF.8040806@in.waw.pl","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-22T23:00:56Z","receivedAt":"2012-03-22T23:00:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 22, 2012 at 09:00:31PM +0100, Zbigniew Jędrzejewski-Szmek wrote:\n\n> Maybe:\n> --- 8< ---\n> When set, case-insensitive comparisons will be used when internally\n> comparing file names.\n> \n> The default is false, but when a new repository is created by\n> git-clone[1] or git-init[1], git will probe the filesystem and set it\n> to `true` if the filesystem is case-insensitive.\n> \n> On case-insensitive filesystems like FAT, NTFS and HSF+, names that\n> differ only in capitalization, like \"Makefile\" and \"makefile\", refer\n> to the same file. While such filesystems usually preserve the\n> capitalization used during file creation, tools designed for such\n> filesystems will often modify capitalization when saving files and\n> when displaying filenames. Enabling core.ignorecase causes git to\n> ignore case-only differences in file names.\n> \n> Enabling core.ignorecase on a case insensitive filesystem does\n> not make sense, because filenames with different capitalization will\n> still be treated as different by the filesystem.\n> --- >8 ---\n\nFrom his response, I guess Junio does not agree, but this is my favorite\nof the texts proposed so far.\n\n-Peff\n\nPS If we do use it, it needs s/HSF/HFS/.\n"},{"id":"187542","messageId":"7vty1guslx.fsf@alter.siamese.dyndns.org","threadId":"30020","inReplyTo":"20120322230056.GC14874@sigill.intra.peff.net","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-22T23:24:26Z","receivedAt":"2012-03-22T23:24:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Mar 22, 2012 at 09:00:31PM +0100, Zbigniew Jędrzejewski-Szmek wrote:\n>\n>> Maybe:\n>> --- 8< ---\n>> When set, case-insensitive comparisons will be used when internally\n>> comparing file names.\n>> \n>> The default is false, but when a new repository is created by\n>> git-clone[1] or git-init[1], git will probe the filesystem and set it\n>> to `true` if the filesystem is case-insensitive.\n>> \n>> On case-insensitive filesystems like FAT, NTFS and HSF+, names that\n>> differ only in capitalization, like \"Makefile\" and \"makefile\", refer\n>> to the same file. While such filesystems usually preserve the\n>> capitalization used during file creation, tools designed for such\n>> filesystems will often modify capitalization when saving files and\n>> when displaying filenames. Enabling core.ignorecase causes git to\n>> ignore case-only differences in file names.\n>> \n>> Enabling core.ignorecase on a case insensitive filesystem does\n>> not make sense, because filenames with different capitalization will\n>> still be treated as different by the filesystem.\n>> --- >8 ---\n>\n> From his response, I guess Junio does not agree, but this is my favorite\n> of the texts proposed so far.\n\nI do not care too deeply, as long as we do not paint ourselves in a corner\nby saying things that we do not have to say and end up sounding as if we\nare defining what the undefined behaviour should be.\n\nIf the change of the presentation order seen above is reverted (in other\nwords, drop the first paragraph, move the second paragraph to the very\nend), I wouldn't mind the above too much.\n\n> PS If we do use it, it needs s/HSF/HFS/.\n\nThat too.\n"},{"id":"187562","messageId":"87pqc3ei08.fsf@thomas.inf.ethz.ch","threadId":"30020","inReplyTo":"7v8viswdho.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-03-23T10:20:07Z","receivedAt":"2012-03-23T10:20:07Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> PJ Weisberg writes:\n>\n>> On Wed, Mar 21, 2012 at 4:58 PM, Junio C Hamano wrote:\n>>\n>>> underlying system calls like open(\"foo\") will *not* magically start\n>>> returning a file descriptor opened for \"FOO\" if your filesystem is not\n>>> case insensitive.\n>>\n>> No, but magic_open(\"foo\") might, if someone had put forth the effort\n>> to write a function called magic_open.\n>\n> Exactly.\n>\n> That is why we avoid describing what happens when you set it on a case\n> sensitive filesystem, to leave the door open for such a cleverness.\n>\n> It may still be a mistake in the manual that we did not explicitly say\n> that setting core.ignorecase on a case sensitive system will give you an\n> undefined behaviour.\n\nHow about trying to read \"HEAD\" as \"head\" instead when core.ignorecase\nis true? That would allow us to catch such misconfiguration (which I\nimagine can also happen accidentally if you mv a repository across FS\nboundaries) and tell the user about it.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"187590","messageId":"7v62dvus3f.fsf@alter.siamese.dyndns.org","threadId":"30020","inReplyTo":"87pqc3ei08.fsf@thomas.inf.ethz.ch","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-23T17:47:48Z","receivedAt":"2012-03-23T17:47:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> How about trying to read \"HEAD\" as \"head\" instead when core.ignorecase\n> is true? That would allow us to catch such misconfiguration (which I\n> imagine can also happen accidentally if you mv a repository across FS\n> boundaries) and tell the user about it.\n\nDo you mean something like this?\n\nI do not like it. It essentially amounts to checking with the FS every\ntime we run Git.\n\n config.c | 9 +++++++++\n 1 file changed, 9 insertions(+)\n\ndiff --git a/config.c b/config.c\nindex 68d3294..8783937 100644\n--- a/config.c\n+++ b/config.c\n@@ -575,7 +575,16 @@ static int git_default_core_config(const char *var, const char *value)\n \t}\n \n \tif (!strcmp(var, \"core.ignorecase\")) {\n+\t\tstatic int true_case; /* 0: unknown, 1: sensitive, 2: fat */\n \t\tignore_case = git_config_bool(var, value);\n+\t\tif (ignore_case) {\n+\t\t\tif (!true_case) {\n+\t\t\t\ttrue_case = fs_is_case_sensitive() ? 1 : 2;\n+\t\t\t\tif (true_case == 2)\n+\t\t\t\t\twarn(\"Whoa\");\n+\t\t\t}\n+\t\t\tignore_case = true_case >> 1;\n+\t\t}\n \t\treturn 0;\n \t}\n \n"},{"id":"187600","messageId":"20120323184823.GA14711@sigill.intra.peff.net","threadId":"30020","inReplyTo":"7v62dvus3f.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-23T18:48:44Z","receivedAt":"2012-03-23T18:48:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 23, 2012 at 10:47:48AM -0700, Junio C Hamano wrote:\n\n> Thomas Rast writes:\n> \n> > How about trying to read \"HEAD\" as \"head\" instead when core.ignorecase\n> > is true? That would allow us to catch such misconfiguration (which I\n> > imagine can also happen accidentally if you mv a repository across FS\n> > boundaries) and tell the user about it.\n> \n> Do you mean something like this?\n> \n> I do not like it. It essentially amounts to checking with the FS every\n> time we run Git.\n\nI think Thomas's suggestion is to piggy-back it onto an existing file\nlookup (\"head\" instead of \"HEAD\"), so you aren't doing any extra work.\nHowever, I'm not sure that would be sufficient. If I copy a repo from a\ncase-insensitive filesystem to a case-sensitive one, what will the case\nof \"HEAD\" be on the new filesystem?\n\nIf the original filesystem was case-preserving, I would expect \"HEAD\".\nBut on a true caseless filesystem, it could be either. Of course,\ncurrent git would already blow up if the file was copied as \"head\",\nwhich makes me think this is probably a rare case. So maybe that is not\nworth worrying about.\n\nI dunno. I think Thomas's idea is clever, but is this actually a problem\nin practice? The current discussion seems more like a documentation bug,\nand I don't remember seeing anybody reporting issues moving a repo\nacross filesystems (presumably most people use clone or push, which\nhandle this properly).\n\n-Peff\n"},{"id":"187602","messageId":"20120323185743.GA15063@sigill.intra.peff.net","threadId":"30020","inReplyTo":"20120323184823.GA14711@sigill.intra.peff.net","subject":"Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-23T18:57:43Z","receivedAt":"2012-03-23T18:57:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 23, 2012 at 02:48:44PM -0400, Jeff King wrote:\n\n> I think Thomas's suggestion is to piggy-back it onto an existing file\n> lookup (\"head\" instead of \"HEAD\"), so you aren't doing any extra work.\n> However, I'm not sure that would be sufficient. If I copy a repo from a\n> case-insensitive filesystem to a case-sensitive one, what will the case\n> of \"HEAD\" be on the new filesystem?\n> \n> If the original filesystem was case-preserving, I would expect \"HEAD\".\n> But on a true caseless filesystem, it could be either. Of course,\n> current git would already blow up if the file was copied as \"head\",\n> which makes me think this is probably a rare case. So maybe that is not\n> worth worrying about.\n\nAs soon as I sent this, I had two additional thoughts:\n\n 1. You could probably just use \"HeAd\", which is unlikely to work\n anywhere except on a case-insensitive filesystem, and gets around\n my objection above.\n\n 2. This still isn't a good test, because it is checking case\n sensitivity of the repo directory, not the working tree, and\n core.ignorecase is about the latter. It's possible to have the two\n on different filesystems with different capabilities.\n\n Though I think the initial test in \"git init\" suffers from the same\n problem (it checks that \"config\" is accessible as \"CoNfIg\"), and I\n have no heard anybody complaining about that.\n\n-Peff\n"}]}