git-rerere

git rerere [clear|forget ...]
git rerere [diff|status|remaining]
git rerere gc

clear
    Clears the conflict resolution cache, effectively forgetting all recorded resolutions.

forget ...
    Forgets the recorded resolution for specific paths. Useful if a previous resolution is no longer desired or correct for a particular file.

diff
    Shows the difference between the conflicted state and the recorded resolution for the current conflict.

status
    Shows paths that have recorded resolutions applied, or are awaiting recording.

remaining
    Lists paths that still have unresolved conflicts after attempting to apply recorded resolutions.

gc
    Performs garbage collection on the rerere cache, removing old and unreachable resolution records to save disk space.

git-rerere (re-use recorded resolution) is a powerful Git feature designed to remember how merge conflicts were resolved, and then automatically apply those resolutions if the same conflict arises again. When rerere.enabled is configured to true (e.g., via git config --global rerere.enabled true), Git records the pre-image and post-image of conflicted files in the .git/rr-cache/ directory whenever you manually resolve a conflict and stage the result. If Git encounters a conflict that matches a previously recorded resolution, it will automatically apply the stored resolution, saving significant time and effort. This is especially useful in workflows involving frequent rebasing, merging diverging branches, or cherry-picking, where the same conflicts might re-appear multiple times. It helps maintain consistency in conflict resolution and reduces manual intervention, streamlining repetitive integration tasks. While it doesn't prevent conflicts, it intelligently automates their resolution based on past experience.

While highly beneficial, git-rerere is not without its considerations. It consumes disk space to store conflict resolutions, though git rerere gc can help manage this. More importantly, it relies on the context of the conflict remaining consistent; if the surrounding code or the nature of the conflict changes significantly, an automatically applied resolution might be incorrect, requiring manual override. It's crucial to review the outcome of automatic resolutions, especially in complex scenarios. It only automates resolution based on prior experience; it does not prevent conflicts from occurring.

The behavior of git-rerere is primarily controlled via Git configuration variables. The most important is rerere.enabled, which when set to true (e.g., git config --global rerere.enabled true), enables automatic recording and reuse of resolutions. Other relevant configurations include rerere.autoupdate (automatically stage the conflict resolution after applying) and rerere.autoreuse (automatically reuse recorded resolutions if found).

When rerere.enabled is true, git-rerere operates largely in the background. After you manually resolve a conflict (e.g., during a merge or rebase) and stage the resolved file (git add <file>), Git automatically records the resolution. If the same conflict later reappears, Git will attempt to automatically apply the recorded resolution, marking the file as resolved in the index. You can then continue the operation (e.g., git commit or git rebase --continue).

The rerere functionality was introduced into Git around version 1.5.1 in 2007. It originated from a series of discussions and patches by Junio C Hamano, the long-time Git maintainer, and others. The primary motivation was to address the common pain point of repeatedly resolving the same merge conflicts, especially when merging a topic branch multiple times into a main branch or during complex rebase operations. Initially, it might have existed as separate scripts or configurations, but it was soon integrated as a core Git feature, enhancing its capabilities for handling complex repository histories and frequent integrations.

git-merge(1), git-rebase(1), git-cherry-pick(1), git-config(1), git-add(1)