What is git-rerere and how does it work?

Question

As I understood, it is useful for the synchronization of projects through the saving of conflict resolution information, but it is not entirely clear to me how to use and configure it.

I want to configure for my continuous integration (CI) environment. Is it recommended do this?

Please don't mark a duplicate with this other question: Are there any downsides to enabling git rerere?. Because my doubt isn't related to "So is there any downside to enabling rerere?. What potential problems can it cause that would not otherwise occur?"

Answer 1

What is git rerere?

As the documentation notes, rerere stands for reuse recorded resolution.

That doesn't really explain what it is, though. It's worth adding first, here, that git rerere itself—the command—is not something you have to run. It has just six subcommands: clear, forget, diff, status, remaining, and gc. None of these record or reuse a resolution—in fact, git rerere clear and git rerere forget <path> just discard some recorded resolutions. The gc command is similar, but refers to ones that are old, rather than current ones.

Most of the work happens from the setting of rerere.enabled (which makes Git run git rerere, with no subcommand, for you, at the appropriate times). You can run git rerere with no subcommands yourself, but this doesn't really do anything important since Git will do that on its own.

git config rerere.enabled true

Once you have set rerere.enabled, when Git does a merge—any merge, including those from git am and git rebase and git cherry-pick and so on, not just those from git merge itself—and hits a conflict, Git will:

2. record (once the merge-as-a-verb hits them) the conflicting diff hunks;
3. wait for you to resolve them manually;
4. record (at git commit time) what you did to resolve them.

There's a step missing here, which is why this is numbered starting at 2. Step 1 is:

1. check for previous recorded resolutions for these conflicts: if they exist, use them to resolve those conflicts automatically.

If the recorded resolutions completely resolve the conflicts, steps 2-4 become redundant. Git may still run them all (I'm not sure that it does) to update the timestamps on the recorded resolutions.

Summary

Once you set rerere.enabled, it's the act of merging itself that both creates the conflicts and (because it automatically runs git rerere with no arguments) records them and then tries to re-use any existing recorded resolutions. It's the act of committing itself that records the final resolutions (because Git automatically runs git rerere again for you). So it is all automatic—you just need to make sure, by running your own git diff commands, that your previous re-used resolutions are correct. If not, just fix them files, add, and commit as usual, and Git will replace the recorded resolutions with the new ones.

Note that you must still git add and git commit! You should always inspect the merge results (and/or run tests)—though you should do this always, regardless of your rerere.enabled setting.

As VonC points out in a comment, if you have existing merge conflict resolutions you did not record earlier, you can "train" the rerere database on those resolutions. There is a contributed script in the Git source to do this; it's also available on-line.

Answer 2

It makes no sense to enable rerere for your CI environment, because your CI environment should never be resolving merge conflicts in the first place. Why do you think you would want it there?

Answer 3

I cannot seem to get the rerere train script to work correctly. It just keeps asking me for my pin to sign what I believe is each and every commit available in the repo.

It should ask you less with git 2.38 (Q3 2022): "rerere-train" script (in contrib/) used to honor commit.gpgSign while recreating the throw-away merges. This has been fixed.

See commit cc391fc (20 Jul 2022) by Celeste Liu (CoelacanthusHex).
^{(Merged by Junio C Hamano -- gitster -- in commit f0f9a03, 01 Aug 2022)}

contrib/rerere-train: avoid useless gpg sign in training

^{Signed-off-by: Celeste Liu}

Users may have configured "git merge"^(man) to always require GPG signing the resulting commits.
We are not running "git merge" to re-create merge commits, but merely to replay merge conflicts, and we will immediately discard the resulting commits; there is no point in signing them.

Override such configuration that forces useless signing from the command line with the "--no-gpg-sign" option.