How to fix fatal: destination exists, source=file.txt, destination=newfile.txt in Git

First, verify what file exists at the destination path:

ls -la newfile.txt
git status

Check if the destination file is tracked by Git:

git ls-files newfile.txt

If this returns the filename, the file is tracked. If empty, it's untracked or doesn't exist in Git's index.

If you intentionally want to overwrite the destination file, use the -f (force) flag:

git mv -f file.txt newfile.txt

Warning: This will permanently overwrite the destination file. Make sure you don't need its contents, or back it up first:

cp newfile.txt newfile.txt.backup
git mv -f file.txt newfile.txt

The -f flag tells Git to proceed even though the destination exists.

If you want to replace the destination file but want more control over the process:

# Remove the destination from Git (keeps it in working directory)
git rm --cached newfile.txt

# Or remove it completely
git rm newfile.txt

# Now perform the move
git mv file.txt newfile.txt

This approach gives you a chance to verify what you're removing before the move.

On case-insensitive filesystems (Windows, macOS), renaming file.txt to File.txt triggers this error because the OS considers them the same file.

Solution 1: Use the -f flag (Git 2.0.1+):

git mv -f file.txt File.txt

Since Git 2.0.1, Git detects case-only renames automatically, but older versions may still need -f.

Solution 2: Two-step rename via intermediate name:

git mv file.txt temp-file.txt
git mv temp-file.txt File.txt

This works on any Git version and any filesystem.

When moving multiple files and some destinations already exist, use -k to skip problematic files instead of failing entirely:

git mv -k *.txt archive/

The -k flag skips any move that would cause an error (destination exists, source doesn't exist, source not tracked). Files that can be moved successfully will be moved.

This is useful for batch reorganization where some files may already be in place.

Before running a batch move, use -n (dry-run) to see what would happen:

git mv -n *.js src/

This shows which files would be moved without actually moving them. Combine with -v for verbose output:

git mv -n -v file.txt newfile.txt

If the dry-run shows "fatal: destination exists", you'll know to use -f or handle the conflict.

After successfully renaming, the change is staged automatically. Commit it:

git status
git commit -m "Rename file.txt to newfile.txt"

Git tracks renames through content similarity detection. To preserve clear history, commit renames separately from content changes when possible.