| blob | 23293d0f4e7efc06600bb9d860fac66412e9217a |
4 <head>
9 /* Debug borders */
11 /*
12 border: 1px solid red;
13 */
14 }
16 body {
18 }
20 a {
23 }
26 }
28 em {
31 }
33 strong {
36 }
38 tt {
40 }
48 }
52 }
53 h2 {
55 }
56 h3 {
58 }
59 h3 + * {
61 }
66 }
68 hr {
70 }
72 p {
75 }
79 }
81 pre {
84 }
86 span#author {
91 }
92 span#email {
93 }
96 }
98 div#footer {
104 }
105 div#footer-text {
108 }
109 div#footer-badges {
112 }
114 div#preamble {
117 }
123 }
127 }
131 }
133 /* Block element titles. */
141 }
144 }
148 }
151 }
154 }
160 }
166 }
171 }
175 }
180 }
183 }
187 }
188 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
191 }
200 }
204 }
209 }
215 dl {
218 }
219 dt {
224 }
227 }
231 }
234 }
237 }
240 }
243 }
246 }
253 }
257 }
258 thead {
261 }
262 tfoot {
264 }
267 }
270 }
271 /* Because the table frame attribute is overriden by CSS in most browsers. */
274 }
278 }
282 }
288 }
291 }
294 }
300 }
303 }
307 }
311 }
315 }
317 div#toctitle {
324 }
329 }
333 }
337 }
341 }
342 /* Overrides for manpage documents */
343 h1 {
348 }
349 h2 {
351 }
354 }
358 }
360 /* Workarounds for IE6's broken and incomplete CSS2. */
366 }
373 }
379 }
384 }
388 }
392 }
397 }
399 /* IE6 sets dynamically generated links as visited. */
401 </style>
402 </head>
403 <body>
405 <h1>
406 git-rerere(1) Manual Page
407 </h1>
410 <p>git-rerere -
411 Reuse recorded resolution of conflicted merges
412 </p>
413 </div>
414 </div>
417 <div class="paragraph"><p><em>git rerere</em> [<em>clear</em>|<em>forget</em> <pathspec>|<em>diff</em>|<em>status</em>|<em>gc</em>]</p></div>
418 </div>
422 the developer sometimes needs to resolve the same conflicts over
423 and over again until the topic branches are done (either merged
426 conflicted automerge results and corresponding hand resolve results
427 on the initial manual merge, and applying previously recorded
428 hand resolutions to their corresponding automerge results.</p></div>
430 <table><tr>
433 </td>
435 enable this command.</td>
436 </tr></table>
437 </div>
438 </div>
441 <div class="paragraph"><p>Normally, <em>git rerere</em> is run without arguments or user-intervention.
442 However, it has several commands that allow it to interact with
443 its working state.</p></div>
447 </dt>
448 <dd>
449 <p>
450 This resets the metadata used by rerere if a merge resolution is to be
452 will automatically invoke this command.
453 </p>
454 </dd>
457 </dt>
458 <dd>
459 <p>
460 This resets the conflict resolutions which rerere has recorded for the current
462 </p>
463 </dd>
466 </dt>
467 <dd>
468 <p>
469 This displays diffs for the current state of the resolution. It is
470 useful for tracking what has changed while the user is resolving
471 conflicts. Additional arguments are passed directly to the system
473 </p>
474 </dd>
477 </dt>
478 <dd>
479 <p>
481 for resolutions.
482 </p>
483 </dd>
486 </dt>
487 <dd>
488 <p>
489 This prunes records of conflicted merges that
490 occurred a long time ago. By default, unresolved conflicts older
492 days are pruned. These defaults are controlled via the
494 variables respectively.
495 </p>
496 </dd>
497 </dl></div>
498 </div>
502 master branch (or upstream) touched since your topic branch
503 forked from it, you may want to test it with the latest master,
504 even before your topic branch is ready to be pushed upstream:</p></div>
507 <pre><tt> o---*---o topic
508 /
509 o---o---o---*---o---o master</tt></pre>
510 </div></div>
512 One way to do it is to pull master into the topic branch:</p></div>
515 <pre><tt> $ git checkout topic
516 $ git merge master
518 o---*---o---+ topic
519 / /
520 o---o---o---*---o---o master</tt></pre>
521 </div></div>
523 file; you need to resolve the conflicts when creating the commit
525 work-in-progress still works with what is in the latest master.</p></div>
527 on the topic. The easiest is to build on top of the test merge
529 ready, pull the topic branch into master, and/or ask the
530 upstream to pull from you. By that time, however, the master or
532 in which case the final commit graph would look like this:</p></div>
535 <pre><tt> $ git checkout topic
536 $ git merge master
537 $ ... work on both topic and master branches
538 $ git checkout master
539 $ git merge topic
541 o---*---o---+---o---o topic
542 / / \
543 o---o---o---*---o---o---o---o---+ master</tt></pre>
544 </div></div>
546 would end up having many such "Merge from master" commits on it,
547 which would unnecessarily clutter the development history.
548 Readers of the Linux kernel mailing list may remember that Linus
549 complained about such too frequent test merges when a subsystem
552 merges, you could blow away the test merge, and keep building on
553 top of the tip before the test merge:</p></div>
556 <pre><tt> $ git checkout topic
557 $ git merge master
558 $ git reset --hard HEAD^ ;# rewind the test merge
559 $ ... work on both topic and master branches
560 $ git checkout master
561 $ git merge topic
563 o---*---o-------o---o topic
564 / \
565 o---o---o---*---o---o---o---o---+ master</tt></pre>
566 </div></div>
568 finally ready and merged into the master branch. This merge
569 would require you to resolve the conflict, introduced by the
571 same conflict you resolved when you created the test merge you
573 conflicted merge using the information from your earlier hand
574 resolve.</p></div>
575 <div class="paragraph"><p>Running the <em>git rerere</em> command immediately after a conflicted
576 automerge records the conflicted working tree files, with the
577 usual conflict markers <tt><<<<<<<</tt>, <tt>=======</tt>, and <tt>>>>>>>></tt> in
578 them. Later, after you are done resolving the conflicts,
580 files. Suppose you did this when you created the test merge of
581 master into the topic branch.</p></div>
584 earlier conflicted automerge, the earlier manual resolution, and
585 the current conflicted automerge.
586 If this three-way merge resolves cleanly, the result is written
587 out to your working tree file, so you do not have to manually
593 records the hand resolve when it is a new conflict, or reuses the earlier hand
595 when committing a merge result. What this means is that you do
596 not have to do anything special yourself (besides enabling
597 the rerere.enabled config variable).</p></div>
599 resolution is recorded, and it will be reused when you do the
600 actual merge later with the updated master and topic branch, as long
601 as the recorded resolution is still applicable.</p></div>
604 development on the topic branch:</p></div>
607 <pre><tt> o---*---o-------o---o topic
608 /
609 o---o---o---*---o---o---o---o master
611 $ git rebase master topic
613 o---*---o-------o---o topic
614 /
615 o---o---o---*---o---o---o---o master</tt></pre>
616 </div></div>
618 up-to-date before your topic is ready to be sent upstream.
619 This would result in falling back to a three-way merge, and it
620 would conflict the same way as the test merge you resolved earlier.
622 conflict.</p></div>
623 </div>
627 </div>
631 </div>
632 </div>
633 </body>
634 </html>