RE: [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit

I just saw this on the cygwin list.

-----Original Message-----
From: Corinna Vinschen
Sent: Friday, August 16, 2013 4:18
To: cygwin@cygwin.com
Subject: [cygwin] Re: Lack of case-sensitive filename 
handling with git 1.7.9-1 for Cygwin 64-bit

On Aug 16 10:32, Kal Sze wrote:

quoted

I have been using Cygwin 32-bit on Windows 7 Profession 

64-bit. I had 

quoted

the HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager\kernel\ObCaseInsensitive registry key set to DWORD 

0x00000000 

quoted

and case-sensitive filename handling has been fully working 

in Cygwin 

quoted

32-bit (as far as I can tell from my usage anyway).

Now that Cygwin 64-bit has been released, I want to try it. 

I notice 

quoted

that git in Cygwin 64-bit does not seem to correctly handle 

filesname 

quoted

that differ only by case.

To reproduce, create a repository in Cygwin 32-bit *with the 
aforementioned registry key set*:

    $ git init case_sensitivity_test; cd case_sensitivity_test

Create two files of different content with similar filenames that 
differ only by case:

    $ echo 'FOO' > FOO.TXT; echo 'foo' > foo.txt

Commit them into the repository:

    $ git add .; git commit -m 'Initial commit'
    [master (root-commit) 16d1b59] Initial commit
     2 files changed, 2 insertions(+), 0 deletions(-)
     create mode 100644 FOO.TXT
     create mode 100644 foo.txt

In Cygwin 32-bit, this looks all green:

    $ git status
    # On branch master
    nothing to commit (working directory clean)
    $ ls
    FOO.TXT  foo.txt

Now, fire up the Cygwin64 terminal and browse to the 

repository, then:

quoted

    $ ls
    FOO.TXT  foo.txt
    $ cat FOO.TXT
    FOO
    $ cat foo.txt
    foo

So `ls` and `cat` both recognize the two different files. However:

    $ git status
    # On branch master
    # Changes not staged for commit:
    #   (use "git add <file>..." to update what will be committed)
    #   (use "git checkout -- <file>..." to discard changes 

in working

quoted

directory)
    #
    #       modified:   foo.txt
    #
    no changes added to commit (use "git add" and/or "git 

commit -a")

quoted

"Oops."

The interesting thing here is, if you try this the other way 
around, you'll see the exact same effect.  If you created the 
above git repo with 64 bit git, everything works exactly as 
in the 32 bit version and the two files are correctly recognized.

I assume the format of the git database files depends on the 
architecture.  Therefore it's probably not advisable to use a 
git repo created under 32 bit git with a 64 bit git and vice versa.

Is this the best explanation for this?

Corinna

-- 
Corinna Vinschen                  Please, send mails 
regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

 

On Fri, Aug 16, 2013 at 07:54:57AM -0400, Jason Pyeron wrote:

quoted

The interesting thing here is, if you try this the other way 
around, you'll see the exact same effect.  If you created the 
above git repo with 64 bit git, everything works exactly as 
in the 32 bit version and the two files are correctly recognized.

I assume the format of the git database files depends on the 
architecture.  Therefore it's probably not advisable to use a 
git repo created under 32 bit git with a 64 bit git and vice versa.

Is this the best explanation for this?

If it is, that is a bug. There should be nothing architecture-dependent
in the index file.

In the test described, it would be worth double-checking that
core.ignorecase is set properly. Git will detect and set that option
when creating the repository based on a test of the filesystem. But it's
possible that there is some weirdness in the packaging or defaults of
the two builds.

It's also worth seeing if newer versions of git behave differently.
There were a lot of bugs in the case-insensitivity code that were fixed
in the late v1.7.x range. Though if I understand the test correctly, we
_shouldn't_ be using the case-insensitive code in the first place.

-Peff