Rename a file's capitalisation on Windows or macOS

Does this match your situation?

• You renamed a file's capitalisation and git status shows nothing.
• Imports fail on Linux or in CI but work locally.
• Both PascalCase and lowercase versions appear on GitHub.
• A colleague on Linux sees duplicate files.

Step-by-step fix

1. Force the rename through Git

   git mv writes both the deletion and the addition into the index even when the filesystem considers them identical. This is the one-command fix.

   step 1Copy

   git mv --force player.cs Player.cs
   git status
   git commit -m "Fix filename capitalisation"
   

2. Or rename through an intermediate name

   If git mv refuses, two renames sidestep the filesystem's case-insensitivity entirely.

   step 2Copy

   git mv player.cs temp-name.cs
   git commit -m "Temporary rename"
   git mv temp-name.cs Player.cs
   git commit -m "Rename to Player.cs"
   

3. Fix a duplicate that already reached the remote

   If both cases are now tracked, remove the wrong one explicitly from the index and commit that.

   step 3Copy

   git ls-files | grep -i player.cs      # shows both if duplicated
   git rm --cached player.cs
   git commit -m "Remove duplicate lowercase filename"
   git push
   

   Show the PowerShell (Windows) version

   PowerShell (Windows)Copy

   git ls-files | Select-String -Pattern "player.cs" -CaseSensitive:$false
   git rm --cached player.cs
   git commit -m "Remove duplicate lowercase filename"
   

4. Make Git case-sensitive in this repository

   Turning off ignorecase makes Git notice case differences itself, at the cost of some odd behaviour on a case-insensitive filesystem. Useful while cleaning up a mess.

   step 4Copy

   git config core.ignorecase false
   git status
   

   💡Leave this off for everyday work on Windows/macOS - it can produce confusing duplicate-path states.

5. Verify the fix from a case-sensitive point of view

   The index is the truth. Check what Git actually has recorded rather than what the filesystem shows you.

   step 5Copy

   git ls-tree -r HEAD --name-only | grep -i player
   

Why this works

Git's index stores exact byte-for-byte pathnames and is fully case-sensitive, but NTFS and APFS are not — so when you rename a file's case, the operating system reports the same path back and Git sees nothing to record. On a case-sensitive filesystem like the one your Linux CI runs, the old and new names are genuinely different files, which is why the mismatch only surfaces there. Forcing the rename writes the correct path into the index regardless of what the filesystem thinks.

How to stop it happening again

• Agree a naming convention and enforce it in code review.
• Add a CI check that fails when two tracked paths differ only by case.
• Use git mv rather than your editor or file explorer for renames.

Commands used in this guide

Frequently asked questions