Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git-windows case sensitive file names not handled properly

Tags:

git

msys

We have the git bare repository in unix that has files with same name that differs only in cases.

Example:

GRANT.sql grant.sql 

When we clone the bare repository from unix in to a windows box, git status detects the file as modified. The working tree is loaded only with grant.sql, but git status compares grant.sql and GRANT.sql and shows the file as modified in the working tree.

I tried using the core.ignorecase false but the result is the same.

Is there any way to fix this issue?

like image 221
user298800 Avatar asked Mar 27 '10 08:03

user298800


People also ask

Is git case sensitive for file names?

The Windows and macOS file systems are case-insensitive (but case-preserving) by default. Most Linux filesystems are case-sensitive. Git was built originally to be the Linux kernel's version control system, so unsurprisingly, it's case-sensitive.

Are file names in Windows case sensitive?

Windows file system treats file and directory names as case-insensitive.

Is git case sensitive for folder names?

Git is a unix based code. its is case sensitive so it will allow you to have the same name in different cases, and as you except windows will not be tolerated for this. There is nothing you can do about it beside renaming your folders.

How do I make a case-insensitive in git?

The cure is to set your ignorecase=false and rename the lowercased files (that git changed that way, not Visual Studio) back to their UsualCase by hand (i.e. 'mv myname MyName').


2 Answers

Windows is case-insensitive (more precisely, case-preserving). There is simply no possible way for two files to exist whose names only differ in case: two filenames which differ only in case are the same filename. Period.

So, Git is walking the repository, checking out one file after the other, until it hits the first one of the two problem files. Git checks it out, then goes further about its business until it hits the second file. Again, Git checks it out. Since from Windows' point of view the filename is the same as the first one, the first file simply gets overwritten with the second one. Which now makes Git think that the first file was changed to have the same content as the second one.

Note that this has nothing to do with Git: exactly the same would happen if you had a tarball, a zipfile or a Subversion repository.

If you want to do development on multiple different platforms, you have to respect the restrictions of those platforms and you have to confine yourself to the lowest common denominator of all the platforms you support. Windows supports ADS, Linux doesn't. OSX supports resource forks, Windows doesn't. BSD supports case-sensitivity, Windows doesn't. So, you can't use any of those. That's just the way it is.

core.ignorecase isn't going to help you here, because that handles exactly the opposite problem.

like image 154
Jörg W Mittag Avatar answered Sep 20 '22 15:09

Jörg W Mittag


I just encountered a similar problem. In my case, the two files with similar names differing only in case were in a subdirectory that wasn't relevant on the Windows clone. Git 1.7 has a sparse checkout feature that lets you exclude certain files from a working copy. To exclude this directory:

git config core.sparsecheckout true echo '*' >.git/info/sparse-checkout echo '!unwanted_dir/' >>.git/info/sparse-checkout git read-tree --reset -u HEAD 

After this, the unwanted_dir/ subdirectory was completely gone from my working copy and Git continues to work with the rest of the files as normal.

If your GRANT.sql and grant.sql are not relevant on the Windows clone, then you can add their names to .git/info/sparse-checkout to exclude those files specifically.

like image 40
Greg Hewgill Avatar answered Sep 20 '22 15:09

Greg Hewgill