{"thread":{"id":"34713","subject":"RE: [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit","startedAt":"2013-08-16T11:54:57Z","lastAt":"2013-08-16T13:21:01Z","messageCount":2,"participants":["Jason Pyeron","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"225340","messageId":"4D206B626EE941D28F6CB93E38293863@black","threadId":"34713","inReplyTo":"20130816081743.GC2562@calimero.vinschen.de","subject":"RE: [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2013-08-16T11:54:57Z","receivedAt":"2013-08-16T11:54:57Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"I just saw this on the cygwin list.\n\n> -----Original Message-----\n> From: Corinna Vinschen\n> Sent: Friday, August 16, 2013 4:18\n> To: cygwin@cygwin.com\n> Subject: [cygwin] Re: Lack of case-sensitive filename \n> handling with git 1.7.9-1 for Cygwin 64-bit\n> \n> On Aug 16 10:32, Kal Sze wrote:\n> > I have been using Cygwin 32-bit on Windows 7 Profession \n> 64-bit. I had \n> > the HKLM\\SYSTEM\\CurrentControlSet\\Control\\Session\n> > Manager\\kernel\\ObCaseInsensitive registry key set to DWORD \n> 0x00000000 \n> > and case-sensitive filename handling has been fully working \n> in Cygwin \n> > 32-bit (as far as I can tell from my usage anyway).\n> > \n> > Now that Cygwin 64-bit has been released, I want to try it. \n> I notice \n> > that git in Cygwin 64-bit does not seem to correctly handle \n> filesname \n> > that differ only by case.\n> > \n> > To reproduce, create a repository in Cygwin 32-bit *with the \n> > aforementioned registry key set*:\n> > \n> > $ git init case_sensitivity_test; cd case_sensitivity_test\n> > \n> > Create two files of different content with similar filenames that \n> > differ only by case:\n> > \n> > $ echo 'FOO' > FOO.TXT; echo 'foo' > foo.txt\n> > \n> > Commit them into the repository:\n> > \n> > $ git add .; git commit -m 'Initial commit'\n> > [master (root-commit) 16d1b59] Initial commit\n> > 2 files changed, 2 insertions(+), 0 deletions(-)\n> > create mode 100644 FOO.TXT\n> > create mode 100644 foo.txt\n> > \n> > In Cygwin 32-bit, this looks all green:\n> > \n> > $ git status\n> > # On branch master\n> > nothing to commit (working directory clean)\n> > $ ls\n> > FOO.TXT foo.txt\n> > \n> > Now, fire up the Cygwin64 terminal and browse to the \n> repository, then:\n> > \n> > $ ls\n> > FOO.TXT foo.txt\n> > $ cat FOO.TXT\n> > FOO\n> > $ cat foo.txt\n> > foo\n> > \n> > So `ls` and `cat` both recognize the two different files. However:\n> > \n> > $ git status\n> > # On branch master\n> > # Changes not staged for commit:\n> > # (use \"git add ...\" to update what will be committed)\n> > # (use \"git checkout -- ...\" to discard changes \n> in working\n> > directory)\n> > #\n> > # modified: foo.txt\n> > #\n> > no changes added to commit (use \"git add\" and/or \"git \n> commit -a\")\n> > \n> > \"Oops.\"\n> \n> The interesting thing here is, if you try this the other way \n> around, you'll see the exact same effect. If you created the \n> above git repo with 64 bit git, everything works exactly as \n> in the 32 bit version and the two files are correctly recognized.\n> \n> I assume the format of the git database files depends on the \n> architecture. Therefore it's probably not advisable to use a \n> git repo created under 32 bit git with a 64 bit git and vice versa.\n\nIs this the best explanation for this?\n\n> \n> \n> Corinna\n> \n> -- \n> Corinna Vinschen Please, send mails \n> regarding Cygwin to\n> Cygwin Maintainer cygwin AT cygwin DOT com\n> Red Hat\n> \n\n\n--\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\n- -\n- Jason Pyeron PD Inc. http://www.pdinc.us -\n- Principal Consultant 10 West 24th Street #100 -\n- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -\n- -\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\nThis message is copyright PD Inc, subject to license 20080407P00.\n\n \n"},{"id":"225341","messageId":"20130816132101.GE20138@sigill.intra.peff.net","threadId":"34713","inReplyTo":"4D206B626EE941D28F6CB93E38293863@black","subject":"Re: [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-16T13:21:01Z","receivedAt":"2013-08-16T13:21:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 16, 2013 at 07:54:57AM -0400, Jason Pyeron wrote:\n\n> > The interesting thing here is, if you try this the other way \n> > around, you'll see the exact same effect. If you created the \n> > above git repo with 64 bit git, everything works exactly as \n> > in the 32 bit version and the two files are correctly recognized.\n> > \n> > I assume the format of the git database files depends on the \n> > architecture. Therefore it's probably not advisable to use a \n> > git repo created under 32 bit git with a 64 bit git and vice versa.\n> \n> Is this the best explanation for this?\n\nIf it is, that is a bug. There should be nothing architecture-dependent\nin the index file.\n\nIn the test described, it would be worth double-checking that\ncore.ignorecase is set properly. Git will detect and set that option\nwhen creating the repository based on a test of the filesystem. But it's\npossible that there is some weirdness in the packaging or defaults of\nthe two builds.\n\nIt's also worth seeing if newer versions of git behave differently.\nThere were a lot of bugs in the case-insensitivity code that were fixed\nin the late v1.7.x range. Though if I understand the test correctly, we\n_shouldn't_ be using the case-insensitive code in the first place.\n\n-Peff\n"}]}