Git missed a filename case change: verify a targeted two-step rename
By ON Lab · Sources checked November 8, 2026
If a filename changed only in capitalization but Git still records the old spelling, inspect the indexed path before editing configuration. A targeted two-step git mv through an unused intermediate name can record the intended rename. Verify the final path and staged diff; changing file contents just to make a changes panel refresh does not prove the filename was corrected.
The reported failure
A GitHub Desktop reader on Windows 11 reported that changing a filename's case, even together with its contents, left the repository showing the old capitalization. A contributor pointed to case-handling behavior and recommended git mv to record the rename.
Our test examines command-line Git on the local filesystem available to us. It does not reproduce the reader's Windows installation or claim a current Desktop UI defect. Filesystem case behavior varies by volume, so “macOS” or “Windows” alone is not a complete description of the directory's behavior.
Read the path Git actually stores
git status --short
git ls-files
git diff --cached --name-statusCompare the exact spelling in the index with the intended spelling in imports, URLs, or documentation. When a case-insensitive filesystem resolves two spellings to the same file, simply opening the destination spelling does not establish which path Git will commit.
Check that the source file is tracked and that there is not already another tracked path whose name differs only by case. A repository with both spellings is a different collision problem. Do not use a force overwrite to turn that ambiguity into a silent replacement.
A targeted rename with an intermediate path
After preserving useful edits, choose a temporary filename that does not exist and is not tracked. For the simple example Report.txt to report.txt:
git mv -- Report.txt rename-temporary.txt
git mv -- rename-temporary.txt report.txt
git diff --cached --name-status
git diff --cached --summary
git ls-filesRun each command separately and read its result. The first move must succeed before the second is attempted. The intermediate name is not a magic reserved name; choose another unused path if it already exists. The double dash separates options from the filename.
The official mv reference states that a successful move updates the index and still needs a commit. A staged rename therefore does not mean the remote repository or deployed site already has the new spelling. Review the actual staged paths before committing through your normal process.
What our local test established
We created a disposable repository and committed Report.txt containing same bytes. In that test directory, looking up report.txt already found the same file, demonstrating case-insensitive behavior there. We did not infer that behavior solely from the operating system label.
Two git mv operations through rename-temporary.txt succeeded. The index listed only report.txt, the staged summary reported the rename, and the final file retained exactly the original contents. No global configuration, remote, user file, or deployment was changed.
This proves the targeted path transition on our test volume. It does not prove that every editor refreshed its view, that a remote received the commit, or that all links and imports referencing the old case were updated.
Check references as well as the filename
A file can be correctly renamed while references still use the old spelling. Search the relevant project files for the old path and review each match in context. An import or URL that happens to work on one local volume may fail in another environment with different path handling.
After an approved reference update, run the project's normal checks in the environment that matters. Do not replace every case-insensitive text match blindly: some matches may refer to another file or display label. This article does not claim that its small text-file test validates a real application's imports or hosting behavior.
Why configuration changes are a separate decision
The reader issue mentions core.ignorecase, but changing a setting is not the same as changing the filesystem's capabilities. This guide uses a targeted rename rather than prescribing a repository-wide or global configuration override. Inspect the current value only as context and follow the repository's platform policy for any change.
Also avoid using a force flag merely because a destination appears to exist. Confirm whether it is the same file through filesystem case handling or a distinct path with useful contents. Preserve both when the situation is uncertain before planning a move.
If the second move fails
Inspect the current working path and index. The successful first move may already be staged, so rerunning the original pair can fail or act on the wrong source. Use the observed intermediate state to plan the next exact move. Do not report completion from the first command's success.
When complete, the index should contain the intended final spelling, the diff should contain only the intended rename and approved content changes, and the file should still have its expected contents. After committing and any authorized deployment, reopen the actual destination to verify its stored casing and references.
Checked November 8, 2026. The two-step rename and index/content checks were executed on a case-insensitive local macOS volume. Windows, Desktop UI, path collisions, imports, remote publication, and deployment were not reproduced.