What does git rerere do, and when does it actually save you work?

## The problem it solves Some conflicts you resolve once. Others you resolve again and again: a topic branch that lives for weeks and is rebased onto a moving trunk every morning; an integration branch that merges five topics and is thrown away and rebuilt nightly; a rebase you abort and restart after realising something else was wrong first. In all of these the *same* textual disagreement, between the same two versions, comes back. Resolving it identically by hand each time is pure repetition — and each repetition is an opportunity to resolve it differently by accident. ## What it records With `rerere.enabled` set to true, Git watches conflicts. At the moment a conflict appears it computes a normalised fingerprint of each conflicted hunk — essentially the pre-image, the two sides as presented. When you finish the resolution (by staging the file and completing the merge or rebase step), Git stores the resolved text against that fingerprint in `.git/rr-cache`. Each recorded resolution is keyed by the conflict content, not by file name, branch or commit, so the same conflict in a renamed file is still recognised. ## What it replays Later, when a merge or rebase produces a conflict whose fingerprint matches a stored one, Git writes the recorded resolution into the working tree instead of leaving the raw markers, and reports that it resolved the path using a previous resolution. Two important qualifications: - By default it stops there. The path is still unmerged in the index, so you review the result and `git add` it. Setting `rerere.autoUpdate` to true makes Git stage the reused resolution as well, which is convenient and correspondingly easier to sleepwalk through. - A partial match is possible: some hunks in a file may be auto-resolved while others still need you. ## The inspection commands `git rerere status` lists the paths for which a resolution is currently being tracked. `git rerere diff` shows what the recorded resolution changes relative to the conflicted state — the fastest way to answer "what exactly did it just do to my file?". `git rerere forget <path>` drops the recorded resolution for that path so the next occurrence conflicts normally again; this is your escape hatch when a resolution was wrong, or when the code around it has moved on and the old resolution no longer makes sense. ## The risks worth naming Rerere's failure mode is confidence. It reapplies a decision you made once, possibly weeks ago, possibly wrongly, without asking. If that decision dropped one side's change, every future occurrence silently drops it too. Because the cache is local and invisible in the diff, two engineers rebasing the same branch can end up with genuinely different results and no obvious explanation. The mitigations are ordinary engineering discipline: read what it did on the first reuse, keep tests running after every rebase step that reports a reuse, and forget resolutions that predate a significant refactor of the region. ## Scope and lifetime The cache is per-repository, stored inside `.git`, and is not transferred by push, fetch or clone — a fresh clone starts with no recorded resolutions. Entries have a limited lifetime and are pruned by garbage collection over time, with separate ages for resolved and unresolved records; the practical implication is that rerere helps with conflicts that recur *soon*, not with one that returns after six months. ## When to recommend it Recommend it to anyone maintaining a long-lived branch against a fast-moving trunk, anyone who rebuilds integration branches, and anyone who has aborted a painful rebase and dreads restarting. Do not present it as a general conflict-reduction strategy: it does not reduce the number of conflicts, only the number of times you decide the same thing. If the same conflict recurs daily for weeks, the deeper answer is usually to land the branch sooner or restructure the file, and rerere is the anaesthetic rather than the cure.