Git suggests enabling rerere to automatically reuse conflict resolutions. This feature remembers how you resolved merge conflicts and reapplies those solutions when the same conflicts appear again.
Git rerere (reuse recorded resolution) is an optional feature that helps developers who frequently encounter the same merge conflicts. When enabled, rerere records how you resolve specific conflicts and automatically applies those resolutions when identical conflicts occur in future merges or rebases. The hint message appears when Git detects that you're resolving a conflict that rerere could have handled automatically if it were enabled. This typically happens during merge operations, rebases, or cherry-picks where similar code changes create recurring conflicts. Git does not enable rerere by default because it introduces a secondary conflict resolution history that operates independently of your commit history. While this automation can save significant time, Git wants you to make an explicit choice to use this feature.
To enable rerere for all your Git repositories, run:
git config --global rerere.enabled trueThis sets the configuration in your global Git config (~/.gitconfig or ~/.config/git/config).
You can also enable automatic staging of rerere-resolved files:
git config --global rerere.autoupdate trueThe autoupdate setting automatically stages files that rerere successfully resolves, reducing manual steps.
If you prefer to enable rerere only for the current repository, use:
git config rerere.enabled trueThis updates the repository-specific config file at .git/config.
You can verify the setting with:
git config --get rerere.enabledThis should output "true" if rerere is enabled.
After enabling rerere, complete your current merge or rebase:
1. Manually resolve the conflicts in your files
2. Stage the resolved files:
git add <resolved-files>3. Complete the merge or rebase:
git commit # For merges
# or
git rebase --continue # For rebasesRerere will now record this conflict resolution in .git/rr-cache for future use.
When you encounter the same conflict again, rerere will automatically apply the recorded resolution.
You can check rerere status during a conflict:
git rerere status # Shows paths with conflicts
git rerere diff # Shows current resolution stateIf rerere resolves conflicts automatically, you'll still need to verify and stage the files before committing.
Cache Management: Git maintains rerere records in .git/rr-cache. By default, Git prunes unresolved conflicts older than 15 days and resolved conflicts older than 60 days. You can adjust these with gc.rerereunresolved and gc.rerereresolved configuration variables.
Conflict Style Configuration: For better rerere performance, consider using the zdiff3 conflict style which provides more context:
git config --global merge.conflictstyle zdiff3Manual Management: You can manage rerere records manually:
- git rerere clear - Clears all rerere metadata (useful if aborting a merge)
- git rerere forget <path> - Forgets the resolution for a specific file
- git rerere gc - Manually runs garbage collection on old records
Important Caveat: Rerere introduces a secondary resolution history orthogonal to your commit graph. A merge you abort or remove from history could still affect future conflict resolution. Always verify rerere-resolved conflicts before committing, especially in critical branches. Rerere leaves files marked as unmerged so you must manually stage them after verification.
Best Use Cases: Rerere is most beneficial for workflows with long-lived feature branches, frequent rebasing, control merges for testing integration, or when switching between merge and rebase strategies for the same branches.
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