Git Rerere
debt(d7/e3/b3/t5)
Closest to 'only careful code review or runtime testing' (d7). Detection that rerere could help requires manually noticing repeated identical conflicts across rebases/merges — git itself provides no warning that you're resolving the same conflict pattern repeatedly. The detection_hints confirm automated detection is 'no', and the only tool listed is git itself which doesn't flag this situation.
Closest to 'simple parameterised fix' (e3). The quick_fix shows enabling rerere is a one-line config change (`git config --global rerere.enabled true`), which would be e1. However, if stale resolutions exist, you need `git rerere forget` for specific paths, and the rr-cache being local means setup is needed per-clone. This slight overhead pushes it to e3.
Closest to 'localised tax' (b3). Rerere is a workflow enhancement that affects only the conflict-resolution phase of git operations. It doesn't impose structural weight on the codebase or architecture — it's a local developer tooling choice. The applies_to scope is version-control/development-workflow, not application architecture, keeping burden contained.
Closest to 'notable trap' (t5). The misconception field explicitly states developers wrongly believe 'rerere just remembers which side you chose' when it actually 'stores the full three-way merge state and matches based on the complete conflict pattern.' Common mistakes confirm: expecting it to work after changing conflict patterns, forgetting to commit after auto-resolution, and assuming it works across clones. These are documented gotchas most git-savvy developers eventually learn.
Also Known As
TL;DR
Explanation
Rerere (Reuse Recorded Resolution) records how you resolve merge conflicts and automatically applies the same resolution when identical conflicts occur in the future. Unlike simple conflict markers, rerere stores the complete three-way merge state: the common ancestor (base), your changes (ours), and incoming changes (theirs). This enables pattern matching across different operations — a conflict resolved during a rebase can be auto-resolved when cherry-picking the same commit elsewhere. Enable with `git config --global rerere.enabled true`. Git stores resolutions in `.git/rr-cache/`. When a known conflict pattern appears, Git silently applies the recorded resolution and stages the file. This is transformative for long-running feature branches that require repeated rebasing onto main — resolve conflicts once, and rerere handles subsequent rebases automatically. The `git rerere` command provides subcommands: `status` shows conflicts being tracked, `diff` shows what rerere would apply, `forget` removes a recorded resolution. Rerere is particularly valuable in workflows involving cherry-picks between release branches where the same logical change creates identical conflict patterns.
Common Misconception
Why It Matters
Common Mistakes
- Not enabling rerere globally — it is disabled by default, so developers miss automatic conflict resolution entirely.
- Expecting rerere to work after changing the conflict pattern — even small changes to context lines create a different conflict signature.
- Forgetting to commit after rerere auto-resolves — the file is staged but still requires a commit to complete the merge.
- Not using `git rerere forget` when a recorded resolution becomes incorrect — stale resolutions silently apply wrong fixes.
- Assuming rerere works across clones — the rr-cache is local to each repository and not pushed to remotes.
Avoid When
- Working on a shared branch where conflict resolutions should be reviewed each time
- The codebase is changing rapidly and conflict patterns rarely repeat
- Team members have different resolution preferences that should not be auto-applied
When To Use
- Long-running feature branches that require frequent rebasing onto main
- Cherry-picking commits between multiple release branches with overlapping changes
- Maintaining parallel branches where the same logical conflicts recur
- Any workflow involving repeated rebases or merges of similar changesets
Code Examples
# Without rerere: repeated manual conflict resolution
# Day 1: Rebase feature onto main
git checkout feature
git rebase main
# CONFLICT in src/payment.php
# Manually resolve, takes 10 minutes
git add src/payment.php
git rebase --continue
# Day 3: Rebase again after main advances
git rebase main
# CONFLICT in src/payment.php — same conflict!
# Manually resolve again, another 10 minutes
# Repeat every few days for long-running branches# Enable rerere globally (one-time setup)
git config --global rerere.enabled true
# Day 1: Rebase feature onto main
git checkout feature
git rebase main
# CONFLICT in src/payment.php
# Resolve conflict manually
git add src/payment.php
git rebase --continue
# Rerere silently records the resolution in .git/rr-cache/
# Day 3: Rebase again after main advances
git rebase main
# Rerere detects the same conflict pattern:
# Resolved 'src/payment.php' using previous resolution.
# File is auto-staged with the recorded resolution
git rebase --continue # No manual work needed
# Useful subcommands:
git rerere status # Show conflicts being tracked
git rerere diff # Show what resolution would be applied
git rerere forget src/payment.php # Remove a bad resolution