Case-sensitive path collisions on case-insensitive file system when I do git clone

Question

when I git clone the repository the following warning appears:

...
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'components/User/index.js'
  'components/user/index.js'

I've been reading and it may be a windows problem since case sensitive is not enabled in the folder paths. I also tried with git config --global core.ignorecase false but it keeps failing.

This problem is faced with all case-insensitive file systems, i.e Windows 10(NTFS) and macOS(APFS).

Does anyone also see this problem?

Answer 1

Use Windows 10's ability to enable case sensitivity on a per-directory basis.

Also, Windows Subsystem for Linux let's you mount Windows folders as case sensitive.

For more information:

How to Enable Case Sensitive File and Folder Names on Windows 10

Per-directory case sensitivity and WSL | Windows Command Line

Answer 2

Definitions

• case-sensitive filesystem: treats john.jpg and JOHN.jpg as two different files and this is allowed.
• case-insensitive filesystem: treats john.jpg and JOHN.jpg as one and the same file which is not allowed.

Problem

'components/User/index.js'
'components/user/index.js'

The problem here is that User and user are not allowed to co-exist at the same time inside the components directory on a case-insensitive filesystem (which is NTFS if you're using Windows 10).

Solution for windows OS

If you have recently cloned the repo and have not done any work on it yet, I recommend that you start over. So remove the clone, then enable case-sensitivity for the directory you intend to clone your repo in, and then clone it anew. The benefit of doing this ahead of the cloning process is that all directories that are created as part of the cloning process by git will be case-sensitive and git will no longer give this warning. Plus, it enables you to clean up the mess.

1. Open a command prompt as an administrator.
2. Go to the directory where you intend to clone your repo. In this example I will use C:\Users\Juan\Desktop. You don't have to cd to this directory to do the next step, just know what your target directory is.
3. Enable case-sensitivity for the target directory. Command: fsutil.exe file SetCaseSensitiveInfo "C:\Users\Juan\Desktop" enable
4. Clone your repo. In this example I will use https://github.com/torvalds/linux.git. Command: git clone https://github.com/torvalds/linux.git
5. (optional): Remove or rename conflicting files and folders if they are the same. You need to verify this by comparing them. To remove, use git rm and to move or copy, use git mv.
6. (optional): Commit and push up your changes to the upstream repo if you have write permission (and possibly after discussing the problem with the rest of the team).
7. (optional): Disable case-sensitivity. Command: fsutil.exe file SetCaseSensitiveInfo "C:\Users\Juan\Desktop" disable

Now you can go back to working on the project.

Source: Windows Central

Solution for macOS

On macOS, you will have to reformat volume as case-insensitive/sensitive or make a new volume altogether. Details

Reflection

You probably ran into this problem because you cloned a repo that was created on a computer that runs Linux or Mac, perhaps it was created by someone else and not you personally. The lesson here is to always be consistent with the way you name things, and this applies to everyone involved in a project. This is one example of what can happen otherwise.

Answer 3

The process of changing your entire file system on macOS is very time-consuming and risky. One can utilize Disk Images as explained here to create virtual containers with specific case-sensitive (i.e., "Journaled") file systems:

• Case-sensitive Journaled HFS+ - Mac OS Extended (Case-sensitive, Journaled)
• Journaled HFS+ - Mac OS Extended (Journaled)

If one likes to use terminal:

• Create an image using hdiutil create -type SPARSE -fs 'Case-sensitive APFS' -volname <volumeName> <fileName>.
• The hdiutil attach <fileName>.sparseimage command, mounts the image into /Volumes/<volumeName> which you can cd into.
• When you are done just unmount the image with diskutil unmount /Volumes/<volumeName>.

You may find more info here.

Answer 4

My solution to this issue (on Windows) was to:

1. Copy the file and save it outside the repo.
2. Delete the file in the repo. This has the effect of showing both files deleted in the git status.
3. Commit the deletion and push
4. Re-add the file to the repo, commit and push

After this my repo was showing as up to date with nothing to commit.