Long-lived topic branches
You often do test merges of master into a feature branch and throw them away to keep the history clean, then let the final merge reuse your earlier fixes.
Git · Command
git rerere
git rerere ("reuse recorded resolution") remembers how you resolved a merge conflict. When the same conflict shows up again, Git applies your earlier fix for you.
Last updated
How it works
When a merge fails, rerere saves a snapshot of the conflicted file (a "preimage") with the conflict markers still in it. After you fix the file, it saves the fixed version too. If the same conflict appears later, rerere runs a three-way merge using three versions: the old conflicted file, your old fix, and the new conflicted file. If that merge is clean, the result goes into your working tree. merge, commit and rebase run rerere for you once it is turned on, and its subcommands let you inspect or reset what it has stored.
Syntax
git rerere [clear | forget <pathspec>… | diff | status | remaining | gc]Parameters
| Name | Type | Description |
|---|---|---|
clear | subcommand | Throws away rerere's working data for the current merge, for when you abandon a resolution. |
forget <pathspec> | subcommand | Deletes the stored resolutions for the current conflicts in the paths you name. |
diff | subcommand | Shows diffs of your resolution so far. Any extra arguments go to the system diff program. |
status | subcommand | Lists the conflicted paths whose resolution rerere will record. |
remaining | subcommand | Lists the conflicted paths that rerere did not resolve automatically. |
gc | subcommand | Deletes old conflict records that rerere no longer needs. |
Key points
- Once rerere is enabled you don't need to run it yourself, because the merge and commit commands call it for you.
- rerere decides what to do by itself: if a conflict is new it saves your fix, and if it has seen the conflict before it reuses the saved fix.
- A saved fix can still apply when the surrounding code has changed, because rerere merges three versions: the old conflict, your old fix and the new conflict.
- Rebase uses the same saved fixes. A rebase that hits the conflict you already fixed in a test merge gets that fix applied again.
- If you saved a wrong fix, 'forget' removes it for the conflicted paths you name, so you can fix and record them again.
- 'gc' cleans up old records. By default it keeps unresolved records for 15 days and resolved ones for 60 days. The settings gc.rerereUnresolved and gc.rerereResolved change these limits.
- While you resolve a conflict, 'git rerere diff' shows what you have changed compared with the original conflicted file.
Common mistakes
- rerere does nothing until you turn it on with the rerere.enabled setting.
- A reused fix changes only the working tree. The file still counts as conflicted, so you must check it and run git add yourself.
- rerere finds conflicts by looking for conflict markers. If a file already has lines that look like markers, rerere may fail to record the fix. You can work around this with the conflict-marker-size setting in gitattributes.
- Some conflicts can't be tracked at all, such as conflicting submodules. 'remaining' lists them, and you have to resolve them by hand.
Example: Do a test merge, throw it away, and get the conflict fixed automatically later
# Turn rerere on once
git config --global rerere.enabled true
# Test merge on the topic branch
git switch topic
git merge master # conflict; rerere saves the preimage
git rerere status # paths rerere is tracking
# ...edit the files to fix the conflict...
git rerere diff # see your fix so far
git add -A && git commit # rerere saves your fix
git reset --hard HEAD^ # undo the test merge
# Later: the real merge
git switch master
git merge topic # the saved fix is applied to the working tree
git rerere remaining # anything rerere could not fix
git diff # check the result
git add -A && git commitThe fix you make during the throwaway test merge is saved, then applied again in the real merge, so you only need to review it and stage it.
When to use it
Rebasing repeatedly
You keep a branch rebased on top of an upstream that moves often, and you don't want to fix the same conflicting hunks on every rebase.
Rebuilding an integration branch
You merge many topic branches into a test branch. If one topic breaks the tests, you redo the merges without it, and the conflicts you already fixed are resolved again automatically.
Interview questions
QWhat does git rerere do, and how do you turn it on?
It records a conflicted merge result together with your manual fix, and later applies that fix when the same conflict comes back. You enable it with the rerere.enabled setting. After that, merge, commit and rebase call it for you.
Follow-up: Does it run during git am or git rebase --abort? Yes: --skip and --abort in git am and git rebase automatically run 'git rerere clear', which throws away the data for the abandoned resolution.
QAfter rerere reuses a fix, can you just run commit?
No. rerere writes the result only to the working tree and does not touch the index, so the file still counts as conflicted. You should review it with git diff (or git diff -c), then stage it with git add.
Follow-up: How can you make rerere stage the result too? Pass --rerere-autoupdate to commands like merge or am to allow it. --no-rerere-autoupdate keeps a manual check step so you can catch bad merges.
QHow does rerere apply an old fix when the code around the conflict has changed?
It does a three-way merge between three versions: the old conflicted file, your old fix, and the new conflicted file. If that merge is clean, the result is written to the working tree. Otherwise you resolve the conflict by hand as usual.
Follow-up: How do you get rid of a wrong fix that rerere saved? Run 'git rerere forget <pathspec>' while the conflict is active, then resolve it again; the new fix will be recorded in its place.
Related
git-mergegit-rebasegit-commitgit-amgit-gcgit-configgitattributes