Skip to main content

What is Git Rerere?

Git rerere records how you resolved a merge conflict and reuses that resolution when the same conflict returns.

Introduction​

Rerere stands for reuse recorded resolution. When a merge or rebase hits the same conflict again, Git can apply the resolution you already chose instead of asking you to edit the markers by hand.

That matters when a long-lived branch keeps meeting the same overlapping edits on main, or when you rebuild an integration branch after dropping one topic. You still review the result. You stop retyping the same fix.

Understanding the Concept​

Enable the feature with configuration:

git config --global rerere.enabled true

You can also enable it for one repository by creating .git/rr-cache. The config setting is clearer and applies everywhere you work.

When a conflict appears, Git stores the conflicted file state as a preimage under .git/rr-cache/. After you resolve the file and finish the merge or rebase, Git stores the resolved content as a postimage. Later conflicts that match the earlier conflicted state are resolved by a three-way merge of the recorded preimage, the recorded postimage, and the new conflicted file.

Definition

Preimage

The conflicted file content, including conflict markers, that rerere records when an automerge first fails.

Definition

Postimage

The resolved file content that rerere records after you hand-resolve a conflict and complete the merge or rebase.

Merge and rebase invoke rerere for you once it is enabled. You do not need to call git rerere on every conflict. Rerere updates the working tree file. It does not stage the resolution, so you still run git add after you verify the result.

ArtifactMeaning
PreimageConflicted state with markers
PostimageHand-resolved file content
.git/rr-cache/Per-repository cache of recorded resolutions

Applying It in Practice​

Rebase a long-lived feature branch onto current main:

git fetch origin
git switch feature/long-lived
git rebase origin/main

When the rebase stops on a conflict, list the paths whose preimages rerere recorded:

git rerere status

Inspect the delta from the recorded conflict to your current working resolution before you stage:

git rerere diff

A typical first encounter prints Recorded preimage for FILE. After you resolve, stage, and continue, Git prints Recorded resolution for FILE. On a later rebase that hits a matching conflict, Git prints Resolved FILE using previous resolution and removes the conflict markers from the working tree. You still verify and git add before continuing:

git add path/to/file
git rebase --continue

If you abort a merge or rebase, Git clears the in-progress rerere metadata for that attempt. To drop a bad recorded resolution for selected paths, use:

git rerere forget path/to/file

Paths that still need a hand fix after autoresolve, including cases rerere cannot track such as conflicting submodules, show up with:

git rerere remaining

Engineering Considerations​

Rerere pays off when the same textual conflict returns across many updates. A long-lived feature branch rebased against a moving main often replays older commits through the same overlapped hunks. Without a cache, you resolve those hunks on every rebase. With rerere enabled, you resolve each recurring conflict once and let later rebases reuse the postimage.

A common alternative to repeated merges is a test merge into current main. You resolve, verify, then reset the merge so the branch history stays free of intermediate merge commits. When you later rebase onto main or perform the final merge, the earlier postimage often applies again. That is how a conflicted merge can become a linear rebase without redoing the same hand edits.

Treat an autoresolved file like any other conflict resolution. Read the combined diff, run the tests that cover the overlapped code, and only then stage. A reused postimage is a prior judgment applied to new parents. The surrounding code may have changed enough that the old answer is wrong. For agent-produced conflicts, keep the same review bar described in How to Fix Merge Conflicts Created by Coding Agents.

Rerere depends on conflict markers in the file. If the file already contains lines that look like markers, recording can fail. Raise conflict-marker-size in .gitattributes for those paths when that happens.

Scaling and Operations​

Teams that merge many topic branches into one integration branch for testing benefit from the same cache. If the aggregate build fails, you rewind the integration tip, drop the bad topic, and merge the remaining branches again. Rerere re-applies the resolutions you already paid for on the branches that remain.

Prune stale cache entries with:

git rerere gc

By default, gc.rerereResolved keeps completed resolutions for 60 days and gc.rerereUnresolved drops abandoned preimages after 15 days. Adjust those values when your integration cycle is longer than the defaults.

Do not treat .git/rr-cache as shared team state unless you deliberately distribute it. Each clone records its own resolutions. Enable rerere.enabled in shared developer setup docs so every machine that rebases the same pull-request stacks builds a useful cache.

Next Steps​