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?

Spragens

Your filesystem is probably case insensitive, so it does not have any way of distinguishing those two file names/paths. To your file system, abc and abC must refer to exactly the same file. Git, which tracks files in a case-sensitive way, is warning you that the repository you are cloning wants to treat abc and abC as different files, yet your filesystem is unable to represent that. Try using a case sensitive FS. Or investigate whether the colliding files are actually meant to hold different contents. – Swage

@Spragens you never accepted an answer. None of them are correct? – Peadar

I know Juan probably isn't using GitHub, or he'd have probably found this solution himself, but, just because this is such a massive pain to solve on macOS, I want to point out to any future readers that if you happen to have the repo on GitHub, you can use GitHub's feature for removing files, to delete one of the copies. – Plane

Answer 1

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.

Oblivion

Does not worked on windows – Lp

@SantanuBiswas pls eleborate on what steps did not work for you. For me, this answer perfectly solved my problem on Windows – Mincing

On my windows with NTFS disk I get: "Error: The request is not supported." – Finance

Ah, fixed by adding Windows Subsystem for Linux : github.com/MicrosoftDocs/windowsserverdocs/issues/977 – Finance

fix for termux, on android: use only internal storage. no way around it! – Camarena

Answer 2

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.

Barbarese

reformat volume seems a bit overkill of a solution, this worked in my case like a charm – Heavyarmed

Worked perfectly fine for change a single file that drove me crazy... – Doughman

By the way, you do not need to push after deleting the two files. – Doughman

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.

Kozak

Answer 4

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

Peadar

In other words, on a admin PowerShell execute: fsutil.exe file setCaseSensitiveInfo "C:\my folder" enable – Brothel

I enabled this, but when I deleted the 'bad' folder, Windows proceeds to delete the 'good' folder. Is there a way to make delete case sensitive? – Beech

@RedRidingHood to get out of the weird hole you are in, you'll have to play some tricks. Once you're out, going forward you'll be fine. Since you didn't supply much detail, i can only guess, so "tricks" along the lines of: make a backup copy of the good folder. Then let Windows delete the good folder, then delete the bad folder, then put your backup of the good one back in place. – Peadar

the solution doesnot work – Lp