1GIT-RERERE(1) Git Manual GIT-RERERE(1)
2
6 git-rerere - Reuse recorded resolution of conflicted merges
7
9 git rerere [clear|forget [<pathspec>]|diff|status|gc]
10
12 In a workflow employing relatively long lived topic branches, the
13 developer sometimes needs to resolve the same conflicts over and over
14 again until the topic branches are done (either merged to the "release"
15 branch, or sent out and accepted upstream).
16 This command assists the developer in this process by recording
18 conflicted automerge results and corresponding hand resolve results on
19 the initial manual merge, and applying previously recorded hand
20 resolutions to their corresponding automerge results.
21 Note
23 You need to set the configuration variable rerere.enabled in order
24 to enable this command.
25
27 Normally, git rerere is run without arguments or user-intervention.
28 However, it has several commands that allow it to interact with its
29 working state.
30 clear
32 This resets the metadata used by rerere if a merge resolution is to
33 be aborted. Calling git am [--skip|--abort] or git rebase
34 [--skip|--abort] will automatically invoke this command.
35 forget <pathspec>
37 This resets the conflict resolutions which rerere has recorded for
38 the current conflict in <pathspec>. The <pathspec> is optional.
39 diff
41 This displays diffs for the current state of the resolution. It is
42 useful for tracking what has changed while the user is resolving
43 conflicts. Additional arguments are passed directly to the system
44 diff command installed in PATH.
45 status
47 Like diff, but this only prints the filenames that will be tracked
48 for resolutions.
49 gc
51 This prunes records of conflicted merges that occurred a long time
52 ago. By default, unresolved conflicts older than 15 days and
53 resolved conflicts older than 60 days are pruned. These defaults
54 are controlled via the gc.rerereunresolved and gc.rerereresolved
55 configuration variables respectively.
56
58 When your topic branch modifies an overlapping area that your master
59 branch (or upstream) touched since your topic branch forked from it,
60 you may want to test it with the latest master, even before your topic
61 branch is ready to be pushed upstream:
62 o---*---o topic
64 /
65 o---o---o---*---o---o master
66 For such a test, you need to merge master and topic somehow. One way to
69 do it is to pull master into the topic branch:
70 $ git checkout topic
72 $ git merge master
73 o---*---o---+ topic
75 / /
76 o---o---o---*---o---o master
77 The commits marked with * touch the same area in the same file; you
80 need to resolve the conflicts when creating the commit marked with +.
81 Then you can test the result to make sure your work-in-progress still
82 works with what is in the latest master.
83 After this test merge, there are two ways to continue your work on the
85 topic. The easiest is to build on top of the test merge commit +, and
86 when your work in the topic branch is finally ready, pull the topic
87 branch into master, and/or ask the upstream to pull from you. By that
88 time, however, the master or the upstream might have been advanced
89 since the test merge +, in which case the final commit graph would look
90 like this:
91 $ git checkout topic
93 $ git merge master
94 $ ... work on both topic and master branches
95 $ git checkout master
96 $ git merge topic
97 o---*---o---+---o---o topic
99 / / \
100 o---o---o---*---o---o---o---o---+ master
101 When your topic branch is long-lived, however, your topic branch would
104 end up having many such "Merge from master" commits on it, which would
105 unnecessarily clutter the development history. Readers of the Linux
106 kernel mailing list may remember that Linus complained about such too
107 frequent test merges when a subsystem maintainer asked to pull from a
108 branch full of "useless merges".
109 As an alternative, to keep the topic branch clean of test merges, you
111 could blow away the test merge, and keep building on top of the tip
112 before the test merge:
113 $ git checkout topic
115 $ git merge master
116 $ git reset --hard HEAD^ ;# rewind the test merge
117 $ ... work on both topic and master branches
118 $ git checkout master
119 $ git merge topic
120 o---*---o-------o---o topic
122 / \
123 o---o---o---*---o---o---o---o---+ master
124 This would leave only one merge commit when your topic branch is
127 finally ready and merged into the master branch. This merge would
128 require you to resolve the conflict, introduced by the commits marked
129 with *. However, this conflict is often the same conflict you resolved
130 when you created the test merge you blew away. git rerere helps you
131 resolve this final conflicted merge using the information from your
132 earlier hand resolve.
133 Running the git rerere command immediately after a conflicted automerge
135 records the conflicted working tree files, with the usual conflict
136 markers <<<<<<<, =======, and >>>>>>> in them. Later, after you are
137 done resolving the conflicts, running git rerere again will record the
138 resolved state of these files. Suppose you did this when you created
139 the test merge of master into the topic branch.
140 Next time, after seeing the same conflicted automerge, running git
142 rerere will perform a three-way merge between the earlier conflicted
143 automerge, the earlier manual resolution, and the current conflicted
144 automerge. If this three-way merge resolves cleanly, the result is
145 written out to your working tree file, so you do not have to manually
146 resolve it. Note that git rerere leaves the index file alone, so you
147 still need to do the final sanity checks with git diff (or git diff -c)
148 and git add when you are satisfied.
149 As a convenience measure, git merge automatically invokes git rerere
151 upon exiting with a failed automerge and git rerere records the hand
152 resolve when it is a new conflict, or reuses the earlier hand resolve
153 when it is not. git commit also invokes git rerere when committing a
154 merge result. What this means is that you do not have to do anything
155 special yourself (besides enabling the rerere.enabled config variable).
156 In our example, when you do the test merge, the manual resolution is
158 recorded, and it will be reused when you do the actual merge later with
159 the updated master and topic branch, as long as the recorded resolution
160 is still applicable.
161 The information git rerere records is also used when running git
163 rebase. After blowing away the test merge and continuing development on
164 the topic branch:
165 o---*---o-------o---o topic
167 /
168 o---o---o---*---o---o---o---o master
169 $ git rebase master topic
171 o---*---o-------o---o topic
173 /
174 o---o---o---*---o---o---o---o master
175 you could run git rebase master topic, to bring yourself up-to-date
178 before your topic is ready to be sent upstream. This would result in
179 falling back to a three-way merge, and it would conflict the same way
180 as the test merge you resolved earlier. git rerere will be run by git
181 rebase to help you resolve this conflict.
182
184 Written by Junio C Hamano <gitster@pobox.com[1]>
185
187 Part of the git(1) suite
188
190 1. gitster@pobox.com
191 mailto:gitster@pobox.com
192Git 1.7.4.4 04/11/2011 GIT-RERERE(1)