Git's rerere (reuse recorded resolution) feature failed to automatically apply a previously recorded conflict resolution. You need to manually resolve the conflict and let rerere learn the new resolution.
This error occurs when Git's rerere ("reuse recorded resolution") feature attempts to automatically resolve a merge conflict based on a previously recorded resolution, but fails to apply it cleanly. The rerere system is designed to remember how you resolved a particular conflict and automatically apply that same resolution when the identical conflict appears again. When you see "CONFLICT (rerere): conflict not auto-resolved", Git is telling you that: 1. It recognized a conflict that rerere has seen before 2. It attempted to apply the previously recorded resolution 3. The three-way merge between the old conflict, old resolution, and new conflict did not produce a clean result This typically happens when the context around the conflict has changed enough that the previous resolution cannot be applied cleanly, or when the conflict markers themselves don't "cleanly nest" as rerere requires. The feature relies on conflict markers in the file to detect and match conflicts, so any modifications to the surrounding context can prevent automatic resolution.
First, identify which files rerere was unable to auto-resolve:
# Show files with conflicts that weren't auto-resolved
git rerere remaining
# Show the current status of rerere
git rerere status
# See all files with merge conflicts
git statusThe git rerere remaining command specifically shows paths that rerere couldn't handle, including:
- Files where the previous resolution couldn't be applied
- Conflicting submodules (which rerere cannot track)
- Files with malformed conflict markers
Since rerere couldn't auto-resolve, you need to manually fix the conflict:
# Open the conflicted file in your editor
code path/to/conflicted-file.txt
# Or use your configured merge tool
git mergetoolLook for the conflict markers in the file:
<<<<<<< HEAD
Your changes here
=======
Incoming changes here
>>>>>>> branch-nameEdit the file to resolve the conflict by:
1. Removing the conflict markers (<<<<<<<, =======, >>>>>>>)
2. Keeping the correct code (yours, theirs, or a combination)
3. Saving the file
After resolving, stage the file:
git add path/to/conflicted-file.txtRerere will automatically record this new resolution for future use.
Once you've resolved the conflict manually, rerere will learn the new resolution:
# After staging the resolved file
git add path/to/resolved-file.txt
# Rerere automatically records the resolution
# You can verify with:
git rerere status
# Continue with your merge or rebase
git merge --continue
# or
git rebase --continueThe next time Git encounters the same conflict pattern, rerere will apply your new resolution.
Important: Rerere doesn't auto-commit or auto-stage. Even when it successfully applies a resolution, you still need to:
1. Review the changes with git diff
2. Stage the file with git add
3. Complete the merge/rebase
If rerere recorded an incorrect resolution that's causing problems, you can forget it:
# Forget the resolution for a specific file
git rerere forget path/to/file.txt
# This removes the recorded pre-image and post-image for that fileAfter forgetting the resolution:
1. Abort and restart your merge/rebase
2. Resolve the conflict correctly
3. Rerere will record the new resolution
# Example workflow to fix a bad resolution
git merge --abort
git rerere forget path/to/problematic-file.txt
git merge feature-branch
# Now resolve the conflict correctly
git add path/to/problematic-file.txt
git merge --continueAlternatively, you can restore the original conflict markers without forgetting the resolution:
# Restore original conflict markers to see the raw conflict
git checkout -m path/to/file.txtMake sure rerere is properly enabled in your Git configuration:
# Check if rerere is enabled
git config --get rerere.enabled
# Enable rerere globally
git config --global rerere.enabled true
# Optional: Auto-stage rerere-resolved files
git config --global rerere.autoupdate trueConfiguration options:
| Setting | Description |
|---------|-------------|
| rerere.enabled | Enable/disable rerere (true/false) |
| rerere.autoupdate | Auto-stage resolved files (true/false) |
Note on autoupdate: Setting rerere.autoupdate true automatically stages files that rerere successfully resolves. However, you should still review changes before committing. Use --no-rerere-autoupdate flag on merge/rebase to override this for a specific operation.
# Merge without auto-staging rerere resolutions
git merge feature-branch --no-rerere-autoupdateIf you have many outdated or problematic recorded resolutions, you can clear the cache:
# Show rerere cache directory
ls .git/rr-cache/
# Remove all recorded resolutions (use with caution!)
rm -rf .git/rr-cache/*
# Or prune old resolutions automatically
git rerere gcDefault retention periods for `git rerere gc`:
- Unresolved conflicts: 15 days
- Resolved conflicts: 60 days
You can configure these:
# Change retention for unresolved conflicts (in days)
git config --global gc.rerereUnresolved 30
# Change retention for resolved conflicts (in days)
git config --global gc.rerereResolved 90After clearing the cache, you'll need to re-record resolutions as you encounter conflicts again.
### How Rerere Works Internally
Rerere stores conflict information in the .git/rr-cache/ directory:
.git/rr-cache/
├── <conflict-hash>/
│ ├── preimage # The conflicted state
│ └── postimage # Your resolutionWhen a conflict occurs, Git:
1. Strips some data from the conflict to make it more general
2. Creates a hash of the conflict
3. Stores the conflict as a "preimage"
4. When you commit, stores your resolution as "postimage"
For auto-resolution to work, the three-way merge between:
- The old preimage (original conflict)
- The old postimage (your resolution)
- The new conflict
...must succeed cleanly.
### Limitations of Rerere
Binary files: Rerere only works with text files. Binary file conflicts always require manual resolution.
Submodules: Conflicting submodules cannot be tracked by rerere. The message "rerere: conflict not auto-resolved" will always appear for submodule conflicts.
Nested conflicts: If conflict markers don't cleanly nest (e.g., overlapping or malformed markers), rerere cannot parse them:
<<<<<<< HEAD
some code
<<<<<<< HEAD # Nested marker - problematic
more code
=======Lines resembling markers: If your code contains lines that look like conflict markers (<<<<<<<, =======, >>>>>>>), rerere may fail.
### Training Rerere from Existing Merges
You can "train" rerere from existing merge commits using the provided script:
# Train rerere from recent merge commits
sh /path/to/git/contrib/rerere-train.sh HEAD~10..HEAD
# Train from all merges on a branch
sh /path/to/git/contrib/rerere-train.sh main
# Overwrite existing recordings
sh /path/to/git/contrib/rerere-train.sh --overwrite HEAD~5..HEADThis script walks through merge commits and records the resolutions so rerere can use them in the future.
### Debugging Rerere Issues
# See what rerere is doing with verbose output
GIT_TRACE=1 git merge branch-name 2>&1 | grep rerere
# Check the hash of a conflict
git rerere diff
# Show what resolution would be applied
cat .git/rr-cache/<hash>/postimage### Disabling Rerere for Specific Operations
If rerere is causing problems with a particular merge:
# Disable for a single merge
git -c rerere.enabled=false merge branch-name
# Or disable autoupdate only
git merge branch-name --no-rerere-autoupdate### Best Practices for Long-Running Branches
When working with integration branches:
1. Record resolutions early: Resolve conflicts carefully the first time
2. Test after auto-resolution: Always verify rerere-applied resolutions are correct
3. Use autoupdate cautiously: Disable it if you want to review every resolution
4. Clear cache periodically: Run git rerere gc to remove stale resolutions
5. Share resolutions: The .git/rr-cache directory can be shared among team members (though this is rarely done)
warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server