| blob | 789c15dbf903f6b82bd7e6a190c5166ccb9f2b78 |
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 }
129 }
133 }
135 /* Block element titles. */
143 }
146 }
150 }
153 }
156 }
162 }
168 }
176 }
181 }
185 }
189 }
190 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
193 }
202 }
206 }
211 }
217 dl {
220 }
221 dt {
226 }
229 }
233 }
236 }
239 }
242 }
245 }
248 }
255 }
259 }
263 }
264 tfoot {
266 }
269 }
272 }
273 /* Because the table frame attribute is overriden by CSS in most browsers. */
276 }
280 }
284 }
290 }
293 }
296 }
302 }
305 }
309 }
313 }
317 }
321 }
326 }
330 }
340 }
345 }
347 div#toc {
349 }
351 div#toctitle {
358 }
363 }
367 }
371 }
375 }
376 /* Overrides for manpage documents */
377 h1 {
382 }
383 h2 {
385 }
388 }
392 }
394 /* Workarounds for IE6's broken and incomplete CSS2. */
400 }
407 }
413 }
418 }
422 }
426 }
431 }
433 /* IE6 sets dynamically generated links as visited. */
435 </style>
437 /*<![CDATA[*/
441 /////////////////////////////////////////////////////////////////////
442 // Table Of Contents generator
443 /////////////////////////////////////////////////////////////////////
445 /* Author: Mihai Bazon, September 2002
446 * http://students.infoiasi.ro/~mishoo
447 *
448 * Table Of Content generator
449 * Version: 0.4
450 *
451 * Feel free to use this script under the terms of the GNU General Public
452 * License, as long as you do not remove or alter this notice.
453 */
455 /* modified by Troy D. Hanson, September 2006. License: GPL */
456 /* modified by Stuart Rackham, 2006, 2009. License: GPL */
458 // toclevels = 1..4.
468 }
470 }
476 }
481 // Function that scans the DOM tree for header elements (the DOM2
482 // nodeIterator API would be a better technique but not supported by all
483 // browsers).
490 }
492 }
493 }
494 }
497 }
512 }
515 },
518 /////////////////////////////////////////////////////////////////////
519 // Footnotes generator
520 /////////////////////////////////////////////////////////////////////
522 /* Based on footnote generation code from:
523 * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
524 */
534 n++;
535 // Use [\s\S] in place of . so multi-line matches work.
536 // Because JavaScript has no s (dotall) regex flag.
547 }
548 }
552 // Process footnoterefs.
561 }
562 }
563 }
564 }
566 }
567 /*]]>*/
568 </script>
569 </head>
570 <body>
572 <h1>
573 git-rerere(1) Manual Page
574 </h1>
577 <p>git-rerere -
578 Reuse recorded resolution of conflicted merges
579 </p>
580 </div>
581 </div>
586 <div class="verseblock-content"><em>git rerere</em> [<em>clear</em>|<em>forget</em> <pathspec>|<em>diff</em>|<em>status</em>|<em>gc</em>]</div>
588 </div></div>
589 </div>
593 the developer sometimes needs to resolve the same conflicts over
594 and over again until the topic branches are done (either merged
597 conflicted automerge results and corresponding hand resolve results
598 on the initial manual merge, and applying previously recorded
599 hand resolutions to their corresponding automerge results.</p></div>
601 <table><tr>
604 </td>
606 enable this command.</td>
607 </tr></table>
608 </div>
609 </div>
612 <div class="paragraph"><p>Normally, <em>git rerere</em> is run without arguments or user-intervention.
613 However, it has several commands that allow it to interact with
614 its working state.</p></div>
618 </dt>
619 <dd>
620 <p>
621 This resets the metadata used by rerere if a merge resolution is to be
623 will automatically invoke this command.
624 </p>
625 </dd>
628 </dt>
629 <dd>
630 <p>
631 This resets the conflict resolutions which rerere has recorded for the current
633 </p>
634 </dd>
637 </dt>
638 <dd>
639 <p>
640 This displays diffs for the current state of the resolution. It is
641 useful for tracking what has changed while the user is resolving
642 conflicts. Additional arguments are passed directly to the system
644 </p>
645 </dd>
648 </dt>
649 <dd>
650 <p>
652 for resolutions.
653 </p>
654 </dd>
657 </dt>
658 <dd>
659 <p>
660 This prunes records of conflicted merges that
661 occurred a long time ago. By default, unresolved conflicts older
663 days are pruned. These defaults are controlled via the
665 variables respectively.
666 </p>
667 </dd>
668 </dl></div>
669 </div>
673 master branch (or upstream) touched since your topic branch
674 forked from it, you may want to test it with the latest master,
675 even before your topic branch is ready to be pushed upstream:</p></div>
678 <pre><tt> o---*---o topic
679 /
680 o---o---o---*---o---o master</tt></pre>
681 </div></div>
683 One way to do it is to pull master into the topic branch:</p></div>
686 <pre><tt> $ git checkout topic
687 $ git merge master
689 o---*---o---+ topic
690 / /
691 o---o---o---*---o---o master</tt></pre>
692 </div></div>
694 file; you need to resolve the conflicts when creating the commit
696 work-in-progress still works with what is in the latest master.</p></div>
698 on the topic. The easiest is to build on top of the test merge
700 ready, pull the topic branch into master, and/or ask the
701 upstream to pull from you. By that time, however, the master or
703 in which case the final commit graph would look like this:</p></div>
706 <pre><tt> $ git checkout topic
707 $ git merge master
708 $ ... work on both topic and master branches
709 $ git checkout master
710 $ git merge topic
712 o---*---o---+---o---o topic
713 / / \
714 o---o---o---*---o---o---o---o---+ master</tt></pre>
715 </div></div>
717 would end up having many such "Merge from master" commits on it,
718 which would unnecessarily clutter the development history.
719 Readers of the Linux kernel mailing list may remember that Linus
720 complained about such too frequent test merges when a subsystem
723 merges, you could blow away the test merge, and keep building on
724 top of the tip before the test merge:</p></div>
727 <pre><tt> $ git checkout topic
728 $ git merge master
729 $ git reset --hard HEAD^ ;# rewind the test merge
730 $ ... work on both topic and master branches
731 $ git checkout master
732 $ git merge topic
734 o---*---o-------o---o topic
735 / \
736 o---o---o---*---o---o---o---o---+ master</tt></pre>
737 </div></div>
739 finally ready and merged into the master branch. This merge
740 would require you to resolve the conflict, introduced by the
742 same conflict you resolved when you created the test merge you
744 conflicted merge using the information from your earlier hand
745 resolve.</p></div>
746 <div class="paragraph"><p>Running the <em>git rerere</em> command immediately after a conflicted
747 automerge records the conflicted working tree files, with the
748 usual conflict markers <tt><<<<<<<</tt>, <tt>=======</tt>, and <tt>>>>>>>></tt> in
749 them. Later, after you are done resolving the conflicts,
751 files. Suppose you did this when you created the test merge of
752 master into the topic branch.</p></div>
755 earlier conflicted automerge, the earlier manual resolution, and
756 the current conflicted automerge.
757 If this three-way merge resolves cleanly, the result is written
758 out to your working tree file, so you do not have to manually
764 records the hand resolve when it is a new conflict, or reuses the earlier hand
766 when committing a merge result. What this means is that you do
767 not have to do anything special yourself (besides enabling
768 the rerere.enabled config variable).</p></div>
770 resolution is recorded, and it will be reused when you do the
771 actual merge later with the updated master and topic branch, as long
772 as the recorded resolution is still applicable.</p></div>
775 development on the topic branch:</p></div>
778 <pre><tt> o---*---o-------o---o topic
779 /
780 o---o---o---*---o---o---o---o master
782 $ git rebase master topic
784 o---*---o-------o---o topic
785 /
786 o---o---o---*---o---o---o---o master</tt></pre>
787 </div></div>
789 up-to-date before your topic is ready to be sent upstream.
790 This would result in falling back to a three-way merge, and it
791 would conflict the same way as the test merge you resolved earlier.
793 conflict.</p></div>
794 </div>
798 </div>
799 </div>
804 </div>
805 </div>
806 </body>
807 </html>