# Fix Git Merge Conflict When Rerere Gives Incorrect Resolution

You have rerere (reuse recorded resolution) enabled in Git, and after resolving a merge conflict once, Git auto-resolves it in future merges. But sometimes the auto-resolution is wrong -- it applies the old resolution to a different conflict, creating subtle bugs.

Understanding Rerere

Rerere records how you resolve merge conflicts and automatically applies the same resolution when the same conflict appears again:

```bash # Enable rerere globally git config --global rerere.enabled true

# Or per-repo git config rerere.enabled true ```

The rerere database is stored in .git/rr-cache/. Each conflict "fingerprint" (based on the conflicting hunks) maps to the resolution you provided.

The Problem: Incorrect Auto-Resolution

Consider this scenario:

  1. 1.You merge feature-A into main, resolve a conflict in config.py, and commit
  2. 2.Weeks later, you merge feature-B into main
  3. 3.The conflict in config.py looks similar but has different surrounding context
  4. 4.Rerere applies the old resolution from step 1, which is wrong for this merge

The result: the merge completes without manual intervention, but config.py has the wrong content.

Step 1: Check Rerere Database

View recorded resolutions:

```bash ls .git/rr-cache/ # Shows conflict fingerprints (hash directories)

# Check what's recorded for dir in .git/rr-cache/*/; do echo "=== $(basename $dir) ===" cat "$dir/preimage" 2>/dev/null | head -5 echo "---" cat "$dir/postimage" 2>/dev/null | head -5 echo done ```

Step 2: Clear Incorrect Resolutions

Remove the incorrect resolution from the rerere database:

```bash # Find the conflict git rerere status # Shows unresolved conflicts

# Clear the specific wrong resolution rm -rf .git/rr-cache/<fingerprint-hash>/ ```

Or clear all rerere data:

bash
rm -rf .git/rr-cache/

This forces Git to ask you to resolve all conflicts manually on the next merge.

Step 3: Verify the Resolution Before Committing

Even with rerere, always verify the merge result before committing:

```bash # After merge (before commit) git diff --name-only --diff-filter=U # Shows unresolved files

git diff HEAD # Shows all changes from the merge, including rerere-applied resolutions ```

Review the diff carefully. If rerere applied a wrong resolution, the diff will show it.

Step 4: Use Rerere With Caution on Long-Lived Branches

Rerere works best for short-lived feature branches that are frequently rebased onto main. On long-lived branches, the code diverges significantly, and old resolutions become incorrect.

Disable rerere for specific branches:

bash
# In the branch
git config rerere.enabled false

Step 5: Rerere GC and Expiration

Old resolutions accumulate and can become stale. Clean them up:

```bash # Remove resolutions older than 60 days (default) git rerere gc

# Configure expiration git config rerere.resolved 30 # Keep resolved for 30 days git config rerere.unresolved 10 # Keep unresolved for 10 days ```

The rerere gc command removes stale entries, reducing the chance of incorrect auto-resolution from outdated data.

Step 6: Disable Rerere Auto-Update

You can keep rerere recording but disable auto-application:

bash
git config rerere.autoupdate false

With this setting, rerere still suggests resolutions but does not automatically stage them. You must review and accept each resolution manually:

bash
# After merge conflict
git checkout --conflict=merge config.py  # Re-show the conflict
# Resolve manually
git add config.py
git commit

Step 7: Sharing Rerere Database Across Team

If your team shares a rerere database, one person's resolution can be wrong for another person's merge:

bash
# Share rerere database via remote
git push origin rr-cache:refs/rr-cache

Team members fetch it:

bash
git fetch origin rr-cache:refs/rr-cache
git rerere forget  # Clear local, then repopulate from remote

Warning: Shared rerere databases are risky because different developers may have different resolution preferences. Only share rerere data for well-understood, repeatable conflicts.

Best Practice: Use Rerere for Repetitive Rebasing

The best use case for rerere is when you frequently rebase a long-lived feature branch onto main:

bash
git config rerere.enabled true
git config rerere.autoupdate true

Each time you rebase and encounter the same conflict (e.g., both main and your branch modify the same import statement), rerere resolves it consistently. This is reliable because the conflict is genuinely the same each time.

For merges between different branches with different purposes, keep rerere disabled or set rerere.autoupdate to false.