| blob | 23e3980059ee06cf67c262b247d48a5d49fc103c |
4 <head>
8 /* Debug borders */
10 /*
11 border: 1px solid red;
12 */
13 }
15 body {
17 }
19 a {
22 }
25 }
27 em {
29 }
31 strong {
33 }
35 tt {
37 }
45 }
49 }
50 h2 {
52 }
53 h3 {
55 }
56 h3 + * {
58 }
63 }
65 hr {
67 }
69 p {
72 }
74 pre {
77 }
79 span#author {
84 }
85 span#email {
86 }
87 span#revision {
89 }
91 div#footer {
97 }
98 div#footer-text {
101 }
102 div#footer-badges {
105 }
107 div#preamble,
114 }
118 }
122 }
124 /* Block element titles. */
131 }
134 }
138 }
141 }
144 }
150 }
154 }
159 }
163 }
167 }
170 }
179 }
183 }
188 }
192 }
198 dl {
201 }
202 dt {
206 }
209 }
213 }
216 }
220 }
221 thead {
224 }
225 tfoot {
227 }
232 }
235 }
240 }
243 }
247 }
249 div#toctitle {
256 }
261 }
265 }
269 }
273 }
275 /* Workarounds for IE6's broken and incomplete CSS2. */
281 }
287 }
293 }
297 }
302 }
304 /* IE6 sets dynamically generated links as visited. */
306 </style>
308 </head>
309 <body>
311 <h1>
312 git-rerere(1) Manual Page
313 </h1>
316 <p>git-rerere -
317 Reuse recorded resolution of conflicted merges
318 </p>
319 </div>
320 </div>
323 <div class="para"><p><em>git rerere</em> [<em>clear</em>|<em>forget</em> [<pathspec>]|<em>diff</em>|<em>status</em>|<em>gc</em>]</p></div>
324 </div>
328 the developer sometimes needs to resolve the same conflicts over
329 and over again until the topic branches are done (either merged
332 conflicted automerge results and corresponding hand resolve results
333 on the initial manual merge, and applying previously recorded
334 hand resolutions to their corresponding automerge results.</p></div>
336 <table><tr>
339 </td>
341 enable this command.</td>
342 </tr></table>
343 </div>
344 </div>
347 <div class="para"><p>Normally, <em>git rerere</em> is run without arguments or user-intervention.
348 However, it has several commands that allow it to interact with
349 its working state.</p></div>
351 <dt>
353 </dt>
354 <dd>
355 <p>
356 This resets the metadata used by rerere if a merge resolution is to be
358 will automatically invoke this command.
359 </p>
360 </dd>
361 <dt>
363 </dt>
364 <dd>
365 <p>
366 This resets the conflict resolutions which rerere has recorded for the current
368 </p>
369 </dd>
370 <dt>
372 </dt>
373 <dd>
374 <p>
375 This displays diffs for the current state of the resolution. It is
376 useful for tracking what has changed while the user is resolving
377 conflicts. Additional arguments are passed directly to the system
379 </p>
380 </dd>
381 <dt>
383 </dt>
384 <dd>
385 <p>
387 for resolutions.
388 </p>
389 </dd>
390 <dt>
392 </dt>
393 <dd>
394 <p>
395 This prunes records of conflicted merges that
396 occurred a long time ago. By default, unresolved conflicts older
398 days are pruned. These defaults are controlled via the
400 variables respectively.
401 </p>
402 </dd>
403 </dl></div>
404 </div>
408 master branch (or upstream) touched since your topic branch
409 forked from it, you may want to test it with the latest master,
410 even before your topic branch is ready to be pushed upstream:</p></div>
413 <pre><tt> o---*---o topic
414 /
415 o---o---o---*---o---o master</tt></pre>
416 </div></div>
418 One way to do it is to pull master into the topic branch:</p></div>
421 <pre><tt> $ git checkout topic
422 $ git merge master
424 o---*---o---+ topic
425 / /
426 o---o---o---*---o---o master</tt></pre>
427 </div></div>
429 file; you need to resolve the conflicts when creating the commit
431 work-in-progress still works with what is in the latest master.</p></div>
433 on the topic. The easiest is to build on top of the test merge
435 ready, pull the topic branch into master, and/or ask the
436 upstream to pull from you. By that time, however, the master or
438 in which case the final commit graph would look like this:</p></div>
441 <pre><tt> $ git checkout topic
442 $ git merge master
443 $ ... work on both topic and master branches
444 $ git checkout master
445 $ git merge topic
447 o---*---o---+---o---o topic
448 / / \
449 o---o---o---*---o---o---o---o---+ master</tt></pre>
450 </div></div>
452 would end up having many such "Merge from master" commits on it,
453 which would unnecessarily clutter the development history.
454 Readers of the Linux kernel mailing list may remember that Linus
455 complained about such too frequent test merges when a subsystem
458 merges, you could blow away the test merge, and keep building on
459 top of the tip before the test merge:</p></div>
462 <pre><tt> $ git checkout topic
463 $ git merge master
464 $ git reset --hard HEAD^ ;# rewind the test merge
465 $ ... work on both topic and master branches
466 $ git checkout master
467 $ git merge topic
469 o---*---o-------o---o topic
470 / \
471 o---o---o---*---o---o---o---o---+ master</tt></pre>
472 </div></div>
474 finally ready and merged into the master branch. This merge
475 would require you to resolve the conflict, introduced by the
477 same conflict you resolved when you created the test merge you
479 conflicted merge using the information from your earlier hand
480 resolve.</p></div>
482 automerge records the conflicted working tree files, with the
483 usual conflict markers <tt><<<<<<<</tt>, <tt>=======</tt>, and <tt>>>>>>>></tt> in
484 them. Later, after you are done resolving the conflicts,
486 files. Suppose you did this when you created the test merge of
487 master into the topic branch.</p></div>
490 earlier conflicted automerge, the earlier manual resolution, and
491 the current conflicted automerge.
492 If this three-way merge resolves cleanly, the result is written
493 out to your working tree file, so you do not have to manually
499 records the hand resolve when it is a new conflict, or reuses the earlier hand
501 when committing a merge result. What this means is that you do
502 not have to do anything special yourself (besides enabling
503 the rerere.enabled config variable).</p></div>
505 resolution is recorded, and it will be reused when you do the
506 actual merge later with the updated master and topic branch, as long
507 as the recorded resolution is still applicable.</p></div>
510 development on the topic branch:</p></div>
513 <pre><tt> o---*---o-------o---o topic
514 /
515 o---o---o---*---o---o---o---o master
517 $ git rebase master topic
519 o---*---o-------o---o topic
520 /
521 o---o---o---*---o---o---o---o master</tt></pre>
522 </div></div>
524 up-to-date before your topic is ready to be sent upstream.
525 This would result in falling back to a three-way merge, and it
526 would conflict the same way as the test merge you resolved earlier.
528 conflict.</p></div>
529 </div>
533 </div>
537 </div>
541 </div>
542 </div>
543 </body>
544 </html>