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

GitBEGINNERLOWUpdated Dec 6, 2025· 171 views

This error occurs when you try to rename or move a file using git mv but a file already exists at the destination path. Git refuses to overwrite existing files by default to protect against accidental data loss.

Quick fix

Fixes fatal: destination exists, source=file.txt, destination=newfile.txt

ls -la newfile.txt
git status
  1. Check what exists at the destination
  2. Use the -f flag to force overwrite
  3. Remove the destination file first
  4. Handle case-sensitive renames
git — error
ls -la newfile.txt
git status
fatal: destination exists, source=file.txt, destination=newfile.txt

What this error means

When you run `git mv source destination`, Git attempts to rename or move a tracked file from one location to another. Unlike the regular Unix `mv` command which silently overwrites existing files, Git's `git mv` command has a built-in safety check. If a file already exists at the destination path—whether tracked by Git or not—the command fails with "fatal: destination exists". This is a safety feature designed to prevent you from accidentally overwriting important files or losing uncommitted changes. This error commonly appears when renaming files to match case changes on case-insensitive file systems (Windows, macOS), when reorganizing project structure, or when two files with similar names need to be consolidated.

Typical symptoms

  • git mv command fails immediately with 'fatal: destination exists' message
  • Attempting to rename a file to an existing filename fails
  • Case-sensitive renames fail on Windows or macOS (e.g., file.txt to File.txt)
  • Moving files into a directory that already contains a file with the same name fails
  • Batch rename operations stop at the first conflicting file

Common causes

  1. A file with the destination name already exists in the target directory (most common)
  2. Attempting a case-only rename on a case-insensitive filesystem like NTFS or APFS
  3. The destination file was created but not yet committed, so Git sees both files
  4. A previous failed rename left both source and destination files present
  5. Merge conflicts created duplicate files with similar names
  6. Git index is out of sync with the working directory

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

1Check what exists at the destination

First, verify what file exists at the destination path:

bash
ls -la newfile.txt
git status

Check if the destination file is tracked by Git:

bash
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.

2Use the -f flag to force overwrite

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

bash
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:

bash
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.

3Remove the destination file first

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

bash
# 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.

4Handle case-sensitive renames

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+):

bash
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:

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

This works on any Git version and any filesystem.

5Use the -k flag to skip errors in batch operations

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

bash
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.

6Preview with --dry-run

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

bash
git mv -n *.js src/

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

bash
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.

7Commit the rename

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

bash
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.

Advanced notes

### Git mv Flags Reference

| Flag | Description |
|------|-------------|
| -f, --force | Force rename/move even if destination exists |
| -k | Skip moves that would cause errors |
| -n, --dry-run | Show what would happen without doing it |
| -v | Verbose output showing each file moved |

### git mv vs Regular mv

The git mv command is equivalent to:

bash
mv source destination
git rm source
git add destination

You can use regular mv followed by git add and git rm, but git mv is safer because it checks for conflicts first.

### Preserving History Across Renames

Git doesn't actually store renames—it detects them through content similarity. To view history across renames:

bash
git log --follow -- newfile.txt

For the clearest history, perform renames in isolated commits without other changes.

### Handling Submodules

If moving a submodule, git mv will also update the .gitmodules file and the submodule's core.worktree setting. This only works for submodules initialized with Git 1.7.8+.

### When -f Doesn't Work

If git mv -f still fails, your Git index may be out of sync:

bash
git reset HEAD
git status

Then retry the move operation.

Frequently asked questions

What does "fatal: destination exists, source=file.txt, destination=newfile.txt" mean?
When you run git mv source destination, Git attempts to rename or move a tracked file from one location to another. Unlike the regular Unix mv command which silently overwrites existing files, Git's git mv command has a built-in safety check. If a file already exists at the destination path—whether tracked by Git or not—the command fails with "fatal: destination exists".
How do I fix "fatal: destination exists, source=file.txt, destination=newfile.txt"?
This error occurs when you try to rename or move a file using git mv but a file already exists at the destination path. Git refuses to overwrite existing files by default to protect against accidental data loss.
What causes "fatal: destination exists, source=file.txt, destination=newfile.txt"?
A file with the destination name already exists in the target directory (most common) Attempting a case-only rename on a case-insensitive filesystem like NTFS or APFS The destination file was created but not yet committed, so Git sees both files
Is the "fatal: destination exists, source=file.txt, destination=newfile.txt" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading