7.9 Git Tools - Rerere

Rerere

The git rerere functionality is a bit of a hidden feature.
The name stands for “reuse recorded resolution” and, as the name implies, it allows you to ask Git to remember how you’ve resolved a hunk conflict so that the next time it sees the same conflict, Git can resolve it for you automatically.

There are a number of scenarios in which this functionality might be really handy.
One of the examples that is mentioned in the documentation is when you want to make sure a long-lived topic branch will ultimately merge cleanly, but you don’t want to have a bunch of intermediate merge commits cluttering up your commit history.
With rerere enabled, you can attempt the occasional merge, resolve the conflicts, then back out of the merge.
If you do this continuously, then the final merge should be easy because rerere can just do everything for you automatically.

This same tactic can be used if you want to keep a branch rebased so you don’t have to deal with the same rebasing conflicts each time you do it.
Or if you want to take a branch that you merged and fixed a bunch of conflicts and then decide to rebase it instead — you likely won’t have to do all the same conflicts again.

Another application of rerere is where you merge a bunch of evolving topic branches together into a testable head occasionally, as the Git project itself often does.
If the tests fail, you can rewind the merges and re-do them without the topic branch that made the tests fail without having to re-resolve the conflicts again.

To enable rerere functionality, you simply have to run this config setting:

$ git config --global rerere.enabled true

You can also turn it on by creating the .git/rr-cache directory in a specific repository, but the config setting is clearer and enables that feature globally for you.

Now let’s see a simple example, similar to our previous one.
Let’s say we have a file named hello.rb that looks like this:

#! /usr/bin/env ruby
def hello
puts 'hello world'
end

In one branch we change the word “hello” to “hola”, then in another branch we change the “world” to “mundo”, just like before.

You should notice the new line Recorded preimage for FILE in there.
Otherwise it should look exactly like a normal merge conflict.
At this point, rerere can tell us a few things.
Normally, you might run git status at this point to see what all conflicted:

Now, let’s undo that merge and then rebase it on top of our master branch instead.
We can move our branch back by using git reset as we saw in Reset Demystified.

$ git reset --hard HEAD^
HEAD is now at ad63f15 i18n the hello

Our merge is undone.
Now let’s rebase the topic branch.

$ git checkout i18n-world
Switched to branch 'i18n-world'
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: i18n one word
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging hello.rb
CONFLICT (content): Merge conflict in hello.rb
Resolved 'hello.rb' using previous resolution.
Failed to merge in the changes.
Patch failed at 0001 i18n one word

Now, we got the same merge conflict like we expected, but take a look at the Resolved FILE using previous resolution line.
If we look at the file, we’ll see that it’s already been resolved, there are no merge conflict markers in it.