rerere autoupdate and safe defaults

Enabling rerere is one line, but the settings around it decide whether it saves time or quietly introduces mistakes. The most consequential is rerere.autoUpdate. With it off, rerere writes the recorded resolution into the working file and leaves the file unstaged, so the operation still stops and you must look at it before continuing. With it on, rerere stages the resolution too, and a merge with only known conflicts can complete without you ever seeing them. Neither is always right. This page lays out the trade-off and a recommended set of defaults for individuals, teams and automation, within rerere conflict automation.

When to use this approach

  • You are about to enable rerere for yourself or recommend it to a team.
  • rerere is enabled and you are unsure whether autoupdate should be on.
  • An automated job uses rerere, as in running rerere in CI integration builds.
  • A reused resolution caused a problem and you want to prevent the next one.

Step 1 — Understand what autoupdate changes

Without autoupdate, a reused resolution looks like a conflict you already fixed but have not staged. Git still stops; git status shows the file as unmerged; you review and git add it. With autoupdate, rerere also runs the git add, so the file is no longer unmerged and Git may continue on its own.

rerere with and without autoupdateWithout autoupdate, a reused resolution is written to the file but left unstaged, so the operation stops and you review it. With autoupdate, the resolution is staged too, so an operation whose conflicts are all known can complete without anyone looking.autoUpdate = falseautoUpdate = truereused resolutionwritten, unstagedwritten and stagedoperation stopsyesonly for new conflictsreview forcedyesnospeed on known conflictsone git add eachnoneautoupdate trades a forced review for speed — choose per context 
git config --get rerere.autoUpdate     # empty means false

Step 2 — Choose per context, not globally

The right setting depends on who looks at the result and what happens to it.

Should autoupdate be on here?For your own interactive work, leave it off so every reused resolution is seen. For throwaway integration builds that only feed tests, turn it on. For anything that produces commits that ship, keep it off and require review.Who will look at the resolved result?you, right nowOffgit add after reviewnobody — test-only buildOnthrowaway branchit shipsOffreview mandatorythe danger case is autoupdate on a branch that gets released 
# Personal default: rerere on, autoupdate off
git config --global rerere.enabled true
git config --global rerere.autoUpdate false

# Throwaway integration repository or CI job only
git config rerere.autoUpdate true

Step 3 — Pair rerere with settings that make review quick

If autoupdate is off, reviewing reused resolutions must be cheap or people will stage them blindly. Two settings and one habit help.

git config --global merge.conflictStyle zdiff3      # see the base when you do look at a conflict
git config --global alias.rr '!git rerere status; git rerere diff'

After any conflicted operation stops, run git rr: it lists the files rerere touched and shows each reused resolution as a diff. Reading a short diff is faster than re-reading a conflict.

git merge feature/x
git rr                         # what rerere did
git add $(git rerere status)   # stage after reading
git commit --no-edit

Step 4 — Set expiry to match how long your conflicts recur

Resolved entries are pruned after sixty days and unresolved ones after fifteen, by default. That suits short-lived branches. Long-lived branches and quarterly release merges need longer.

git config --global gc.rerereResolved 180       # days
git config --global gc.rerereUnresolved 30
Expiry settings for different branch lifetimesFor short-lived feature branches the sixty-day default is enough. Long-lived topic branches and quarterly release merges need resolved entries kept for several months, or the oldest resolutions disappear just before they are needed.suggested days to keep resolved entriesfeature branches60 dlong-lived topics180 dquarterly release merges120 dCI integration cache90 drerere refreshes an entry's age every time it reuses it, so active entries never expire

Step 5 — Write the policy down for the team

A shared, written default stops each person from discovering the trade-offs alone. Put the settings in the team’s shared configuration and a short paragraph in the contributing guide.

# team.gitconfig
[rerere]
    enabled = true
    autoUpdate = false
[merge]
    conflictStyle = zdiff3
[gc]
    rerereResolved = 180
    rerereUnresolved = 30
[alias]
    rr = "!git rerere status; git rerere diff"

Distributing a team configuration file is covered in shipping a team gitconfig with includeIf.

Step 6 — Revisit the defaults after an incident

If a reused resolution ever causes a defect, treat it like any other incident: find out which setting allowed it through. Usually the answer is autoupdate on a branch that turned out to matter, or a review habit that slipped. Adjust the shared configuration rather than relying on people to remember, and note the change in the contributing guide.

# Was the defective commit created while autoupdate was on in that repository?
git config --show-origin --get rerere.autoUpdate
# Which reused resolution introduced the problem?
git show --remerge-diff <merge-commit> -- path/to/file

--remerge-diff, covered in reviewing conflict resolutions with remerge-diff, shows exactly how a merge’s result differs from Git’s own automatic merge — which is precisely what rerere contributed.

Validation checklist

Frequently Asked Questions

Does autoupdate affect conflicts rerere has never seen?

No. New conflicts are left in the file with markers and unstaged, as always. Autoupdate only stages files where rerere applied a recorded resolution.

Can rerere ever make a merge succeed that would otherwise fail?

With autoupdate on, yes: if every conflict is known, the merge completes and commits without stopping. With it off, the merge still stops for you to stage the reused resolutions.

Is there a risk rerere applies a resolution in the wrong file?

rerere matches by conflict content, not path, so the same conflicting hunk in two files can share a resolution. That is usually correct — the same conflict deserves the same answer — and reviewing with git rerere diff catches the rare exception.