{
    "content": [
        {
            "type": "text",
            "text": "# git-rerere (man)\n\n## NAME\n\ngit-rerere - Reuse recorded resolution of conflicted merges\n\n## SYNOPSIS\n\ngit rerere [clear|forget <pathspec>|diff|remaining|status|gc]\n\n## DESCRIPTION\n\nIn a workflow employing relatively long lived topic branches, the developer sometimes needs\nto resolve the same conflicts over and over again until the topic branches are done (either\nmerged to the \"release\" branch, or sent out and accepted upstream).\n\n## TLDR\n\n> Reuse fixes for merge conflicts.\n\n- Enable rerere globally:\n  `git config --global rerere.enabled true`\n- Forget a file's recorded resolution:\n  `git rerere forget {{path/to/file}}`\n- Check the status of recorded resolutions:\n  `git rerere status`\n\n*Source: tldr-pages*\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **COMMANDS**\n- **DISCUSSION**\n- **GIT**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n"
        }
    ],
    "structuredContent": {
        "command": "git-rerere",
        "section": "",
        "mode": "man",
        "summary": "git-rerere - Reuse recorded resolution of conflicted merges",
        "synopsis": "git rerere [clear|forget <pathspec>|diff|remaining|status|gc]",
        "tldr_summary": "Reuse fixes for merge conflicts.",
        "tldr_examples": [
            {
                "description": "Enable rerere globally",
                "command": "git config --global rerere.enabled true"
            },
            {
                "description": "Forget a file's recorded resolution",
                "command": "git rerere forget {{path/to/file}}"
            },
            {
                "description": "Check the status of recorded resolutions",
                "command": "git rerere status"
            }
        ],
        "tldr_source": "official",
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 3,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 12,
                "subsections": []
            },
            {
                "name": "COMMANDS",
                "lines": 29,
                "subsections": []
            },
            {
                "name": "DISCUSSION",
                "lines": 115,
                "subsections": []
            },
            {
                "name": "GIT",
                "lines": 5,
                "subsections": []
            }
        ],
        "sections": {
            "NAME": {
                "content": "git-rerere - Reuse recorded resolution of conflicted merges\n",
                "subsections": []
            },
            "SYNOPSIS": {
                "content": "git rerere [clear|forget <pathspec>|diff|remaining|status|gc]\n\n",
                "subsections": []
            },
            "DESCRIPTION": {
                "content": "In a workflow employing relatively long lived topic branches, the developer sometimes needs\nto resolve the same conflicts over and over again until the topic branches are done (either\nmerged to the \"release\" branch, or sent out and accepted upstream).\n\nThis command assists the developer in this process by recording conflicted automerge results\nand corresponding hand resolve results on the initial manual merge, and applying previously\nrecorded hand resolutions to their corresponding automerge results.\n\nNote\nYou need to set the configuration variable rerere.enabled in order to enable this\ncommand.\n",
                "subsections": []
            },
            "COMMANDS": {
                "content": "Normally, git rerere is run without arguments or user-intervention. However, it has several\ncommands that allow it to interact with its working state.\n\nclear\nReset the metadata used by rerere if a merge resolution is to be aborted. Calling git am\n[--skip|--abort] or git rebase [--skip|--abort] will automatically invoke this command.\n\nforget <pathspec>\nReset the conflict resolutions which rerere has recorded for the current conflict in\n<pathspec>.\n\ndiff\nDisplay diffs for the current state of the resolution. It is useful for tracking what has\nchanged while the user is resolving conflicts. Additional arguments are passed directly\nto the system diff command installed in PATH.\n\nstatus\nPrint paths with conflicts whose merge resolution rerere will record.\n\nremaining\nPrint paths with conflicts that have not been autoresolved by rerere. This includes paths\nwhose resolutions cannot be tracked by rerere, such as conflicting submodules.\n\ngc\nPrune records of conflicted merges that occurred a long time ago. By default, unresolved\nconflicts older than 15 days and resolved conflicts older than 60 days are pruned. These\ndefaults are controlled via the gc.rerereUnresolved and gc.rerereResolved configuration\nvariables respectively.\n",
                "subsections": []
            },
            "DISCUSSION": {
                "content": "When your topic branch modifies an overlapping area that your master branch (or upstream)\ntouched since your topic branch forked from it, you may want to test it with the latest\nmaster, even before your topic branch is ready to be pushed upstream:\n\no---*---o topic\n/\no---o---o---*---o---o master\n\n\nFor such a test, you need to merge master and topic somehow. One way to do it is to pull\nmaster into the topic branch:\n\n$ git switch topic\n$ git merge master\n\no---*---o---+ topic\n/           /\no---o---o---*---o---o master\n\n\nThe commits marked with * touch the same area in the same file; you need to resolve the\nconflicts when creating the commit marked with +. Then you can test the result to make sure\nyour work-in-progress still works with what is in the latest master.\n\nAfter this test merge, there are two ways to continue your work on the topic. The easiest is\nto build on top of the test merge commit +, and when your work in the topic branch is finally\nready, pull the topic branch into master, and/or ask the upstream to pull from you. By that\ntime, however, the master or the upstream might have been advanced since the test merge +, in\nwhich case the final commit graph would look like this:\n\n$ git switch topic\n$ git merge master\n$ ... work on both topic and master branches\n$ git switch master\n$ git merge topic\n\no---*---o---+---o---o topic\n/           /         \\\no---o---o---*---o---o---o---o---+ master\n\n\nWhen your topic branch is long-lived, however, your topic branch would end up having many\nsuch \"Merge from master\" commits on it, which would unnecessarily clutter the development\nhistory. Readers of the Linux kernel mailing list may remember that Linus complained about\nsuch too frequent test merges when a subsystem maintainer asked to pull from a branch full of\n\"useless merges\".\n\nAs an alternative, to keep the topic branch clean of test merges, you could blow away the\ntest merge, and keep building on top of the tip before the test merge:\n\n$ git switch topic\n$ git merge master\n$ git reset --hard HEAD^ ;# rewind the test merge\n$ ... work on both topic and master branches\n$ git switch master\n$ git merge topic\n\no---*---o-------o---o topic\n/                     \\\no---o---o---*---o---o---o---o---+ master\n\n\nThis would leave only one merge commit when your topic branch is finally ready and merged\ninto the master branch. This merge would require you to resolve the conflict, introduced by\nthe commits marked with *. However, this conflict is often the same conflict you resolved\nwhen you created the test merge you blew away. git rerere helps you resolve this final\nconflicted merge using the information from your earlier hand resolve.\n\nRunning the git rerere command immediately after a conflicted automerge records the\nconflicted working tree files, with the usual conflict markers <<<<<<<, =======, and >>>>>>>\nin them. Later, after you are done resolving the conflicts, running git rerere again will\nrecord the resolved state of these files. Suppose you did this when you created the test\nmerge of master into the topic branch.\n\nNext time, after seeing the same conflicted automerge, running git rerere will perform a\nthree-way merge between the earlier conflicted automerge, the earlier manual resolution, and\nthe current conflicted automerge. If this three-way merge resolves cleanly, the result is\nwritten out to your working tree file, so you do not have to manually resolve it. Note that\ngit rerere leaves the index file alone, so you still need to do the final sanity checks with\ngit diff (or git diff -c) and git add when you are satisfied.\n\nAs a convenience measure, git merge automatically invokes git rerere upon exiting with a\nfailed automerge and git rerere records the hand resolve when it is a new conflict, or reuses\nthe earlier hand resolve when it is not. git commit also invokes git rerere when committing a\nmerge result. What this means is that you do not have to do anything special yourself\n(besides enabling the rerere.enabled config variable).\n\nIn our example, when you do the test merge, the manual resolution is recorded, and it will be\nreused when you do the actual merge later with the updated master and topic branch, as long\nas the recorded resolution is still applicable.\n\nThe information git rerere records is also used when running git rebase. After blowing away\nthe test merge and continuing development on the topic branch:\n\no---*---o-------o---o topic\n/\no---o---o---*---o---o---o---o   master\n\n$ git rebase master topic\n\no---*---o-------o---o topic\n/\no---o---o---*---o---o---o---o   master\n\n\nyou could run git rebase master topic, to bring yourself up to date before your topic is\nready to be sent upstream. This would result in falling back to a three-way merge, and it\nwould conflict the same way as the test merge you resolved earlier. git rerere will be run by\ngit rebase to help you resolve this conflict.\n\n[NOTE] git rerere relies on the conflict markers in the file to detect the conflict. If the\nfile already contains lines that look the same as lines with conflict markers, git rerere may\nfail to record a conflict resolution. To work around this, the conflict-marker-size setting\nin gitattributes(5) can be used.\n",
                "subsections": []
            },
            "GIT": {
                "content": "Part of the git(1) suite\n\n\n\nGit 2.34.1                                   02/26/2026                                GIT-RERERE(1)",
                "subsections": []
            }
        }
    }
}