1 <?xml version=
"1.0" encoding=
"UTF-8"?>
2 <!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.1//EN"
3 "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
4 <html xmlns=
"http://www.w3.org/1999/xhtml" xml:
lang=
"en">
6 <meta http-equiv=
"Content-Type" content=
"application/xhtml+xml; charset=UTF-8" />
7 <meta name=
"generator" content=
"AsciiDoc 10.2.0" />
8 <title>How to revert a faulty merge
</title>
9 <style type=
"text/css">
10 /* Shared CSS for AsciiDoc xhtml11 and html5 backends */
14 font-family: Georgia,serif;
18 h1, h2, h3, h4, h5, h6,
19 div.title, caption.title,
20 thead, p.table.header,
22 #author, #revnumber, #revdate, #revremark,
24 font-family: Arial,Helvetica,sans-serif;
28 margin:
1em
5%
1em
5%;
33 text-decoration: underline;
49 h1, h2, h3, h4, h5, h6 {
57 border-bottom:
2px solid silver;
77 border:
1px solid silver;
88 ul
> li { color: #aaa; }
89 ul
> li
> * { color: black; }
91 .monospaced, code, pre {
92 font-family:
"Courier New", Courier, monospace;
99 white-space: pre-wrap;
109 #revnumber, #revdate, #revremark {
114 border-top:
2px solid silver;
120 padding-bottom:
0.5em;
124 padding-bottom:
0.5em;
129 margin-bottom:
1.5em;
131 div.imageblock, div.exampleblock, div.verseblock,
132 div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
133 div.admonitionblock {
135 margin-bottom:
1.5em;
137 div.admonitionblock {
139 margin-bottom:
2.0em;
144 div.content { /* Block element content. */
148 /* Block element titles. */
149 div.title, caption.title {
154 margin-bottom:
0.5em;
160 td div.title:first-child {
163 div.content div.title:first-child {
166 div.content + div.title {
170 div.sidebarblock
> div.content {
172 border:
1px solid #dddddd;
173 border-left:
4px solid #f0f0f0;
177 div.listingblock
> div.content {
178 border:
1px solid #dddddd;
179 border-left:
5px solid #f0f0f0;
184 div.quoteblock, div.verseblock {
188 border-left:
5px solid #f0f0f0;
192 div.quoteblock
> div.attribution {
197 div.verseblock
> pre.content {
198 font-family: inherit;
201 div.verseblock
> div.attribution {
205 /* DEPRECATED: Pre version
8.2.7 verse style literal block. */
206 div.verseblock + div.attribution {
210 div.admonitionblock .icon {
214 text-decoration: underline;
216 padding-right:
0.5em;
218 div.admonitionblock td.content {
220 border-left:
3px solid #dddddd;
223 div.exampleblock
> div.content {
224 border-left:
3px solid #dddddd;
228 div.imageblock div.content { padding-left:
0; }
229 span.image img { border-style: none; vertical-align: text-bottom; }
230 a.image:visited { color: white; }
234 margin-bottom:
0.8em;
247 list-style-position: outside;
250 list-style-type: decimal;
253 list-style-type: lower-alpha;
256 list-style-type: upper-alpha;
259 list-style-type: lower-roman;
262 list-style-type: upper-roman;
265 div.compact ul, div.compact ol,
266 div.compact p, div.compact p,
267 div.compact div, div.compact div {
269 margin-bottom:
0.1em;
281 margin-bottom:
0.8em;
284 padding-bottom:
15px;
286 dt.hdlist1.strong, td.hdlist1.strong {
292 padding-right:
0.8em;
298 div.hdlist.compact tr {
307 .footnote, .footnoteref {
311 span.footnote, span.footnoteref {
312 vertical-align: super;
316 margin:
20px
0 20px
0;
320 #footnotes div.footnote {
326 border-top:
1px solid silver;
335 padding-right:
0.5em;
336 padding-bottom:
0.3em;
344 #footer-badges { display: none; }
348 margin-bottom:
2.5em;
356 margin-bottom:
0.1em;
359 div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
376 span.aqua { color: aqua; }
377 span.black { color: black; }
378 span.blue { color: blue; }
379 span.fuchsia { color: fuchsia; }
380 span.gray { color: gray; }
381 span.green { color: green; }
382 span.lime { color: lime; }
383 span.maroon { color: maroon; }
384 span.navy { color: navy; }
385 span.olive { color: olive; }
386 span.purple { color: purple; }
387 span.red { color: red; }
388 span.silver { color: silver; }
389 span.teal { color: teal; }
390 span.white { color: white; }
391 span.yellow { color: yellow; }
393 span.aqua-background { background: aqua; }
394 span.black-background { background: black; }
395 span.blue-background { background: blue; }
396 span.fuchsia-background { background: fuchsia; }
397 span.gray-background { background: gray; }
398 span.green-background { background: green; }
399 span.lime-background { background: lime; }
400 span.maroon-background { background: maroon; }
401 span.navy-background { background: navy; }
402 span.olive-background { background: olive; }
403 span.purple-background { background: purple; }
404 span.red-background { background: red; }
405 span.silver-background { background: silver; }
406 span.teal-background { background: teal; }
407 span.white-background { background: white; }
408 span.yellow-background { background: yellow; }
410 span.big { font-size:
2em; }
411 span.small { font-size:
0.6em; }
413 span.underline { text-decoration: underline; }
414 span.overline { text-decoration: overline; }
415 span.line-through { text-decoration: line-through; }
417 div.unbreakable { page-break-inside: avoid; }
427 margin-bottom:
1.5em;
429 div.tableblock
> table {
430 border:
3px solid #
527bbd;
432 thead, p.table.header {
439 /* Because the table frame attribute is overridden by CSS in most browsers. */
440 div.tableblock
> table[
frame=
"void"] {
443 div.tableblock
> table[
frame=
"hsides"] {
444 border-left-style: none;
445 border-right-style: none;
447 div.tableblock
> table[
frame=
"vsides"] {
448 border-top-style: none;
449 border-bottom-style: none;
460 margin-bottom:
1.5em;
462 thead, p.tableblock.header {
473 border-color: #
527bbd;
474 border-collapse: collapse;
476 th.tableblock, td.tableblock {
480 border-color: #
527bbd;
483 table.tableblock.frame-topbot {
484 border-left-style: hidden;
485 border-right-style: hidden;
487 table.tableblock.frame-sides {
488 border-top-style: hidden;
489 border-bottom-style: hidden;
491 table.tableblock.frame-none {
492 border-style: hidden;
495 th.tableblock.halign-left, td.tableblock.halign-left {
498 th.tableblock.halign-center, td.tableblock.halign-center {
501 th.tableblock.halign-right, td.tableblock.halign-right {
505 th.tableblock.valign-top, td.tableblock.valign-top {
508 th.tableblock.valign-middle, td.tableblock.valign-middle {
509 vertical-align: middle;
511 th.tableblock.valign-bottom, td.tableblock.valign-bottom {
512 vertical-align: bottom;
523 padding-bottom:
0.5em;
524 border-top:
2px solid silver;
525 border-bottom:
2px solid silver;
530 body.manpage div.sectionbody {
535 body.manpage div#toc { display: none; }
540 <script type=
"text/javascript">
542 var asciidoc = { // Namespace.
544 /////////////////////////////////////////////////////////////////////
545 // Table Of Contents generator
546 /////////////////////////////////////////////////////////////////////
548 /* Author: Mihai Bazon, September
2002
549 * http://students.infoiasi.ro/~mishoo
551 * Table Of Content generator
554 * Feel free to use this script under the terms of the GNU General Public
555 * License, as long as you do not remove or alter this notice.
558 /* modified by Troy D. Hanson, September
2006. License: GPL */
559 /* modified by Stuart Rackham,
2006,
2009. License: GPL */
562 toc: function (toclevels) {
564 function getText(el) {
566 for (var i = el.firstChild; i != null; i = i.nextSibling) {
567 if (i.nodeType ==
3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
569 else if (i.firstChild != null)
575 function TocEntry(el, text, toclevel) {
578 this.toclevel = toclevel;
581 function tocEntries(el, toclevels) {
582 var result = new Array;
583 var re = new RegExp('[hH]([
1-'+(toclevels+
1)+'])');
584 // Function that scans the DOM tree for header elements (the DOM2
585 // nodeIterator API would be a better technique but not supported by all
587 var iterate = function (el) {
588 for (var i = el.firstChild; i != null; i = i.nextSibling) {
589 if (i.nodeType ==
1 /* Node.ELEMENT_NODE */) {
590 var mo = re.exec(i.tagName);
591 if (mo && (i.getAttribute(
"class") || i.getAttribute(
"className")) !=
"float") {
592 result[result.length] = new TocEntry(i, getText(i), mo[
1]-
1);
602 var toc = document.getElementById(
"toc");
607 // Delete existing TOC entries in case we're reloading the TOC.
608 var tocEntriesToRemove = [];
610 for (i =
0; i < toc.childNodes.length; i++) {
611 var entry = toc.childNodes[i];
612 if (entry.nodeName.toLowerCase() == 'div'
613 && entry.getAttribute(
"class")
614 && entry.getAttribute(
"class").match(/^toclevel/))
615 tocEntriesToRemove.push(entry);
617 for (i =
0; i < tocEntriesToRemove.length; i++) {
618 toc.removeChild(tocEntriesToRemove[i]);
621 // Rebuild TOC entries.
622 var entries = tocEntries(document.getElementById(
"content"), toclevels);
623 for (var i =
0; i < entries.length; ++i) {
624 var entry = entries[i];
625 if (entry.element.id ==
"")
626 entry.element.id =
"_toc_" + i;
627 var a = document.createElement(
"a");
628 a.href =
"#" + entry.element.id;
629 a.appendChild(document.createTextNode(entry.text));
630 var div = document.createElement(
"div");
632 div.className =
"toclevel" + entry.toclevel;
633 toc.appendChild(div);
635 if (entries.length ==
0)
636 toc.parentNode.removeChild(toc);
640 /////////////////////////////////////////////////////////////////////
641 // Footnotes generator
642 /////////////////////////////////////////////////////////////////////
644 /* Based on footnote generation code from:
645 * http://www.brandspankingnew.net/archive/
2005/
07/format_footnote.html
648 footnotes: function () {
649 // Delete existing footnote entries in case we're reloading the footnodes.
651 var noteholder = document.getElementById(
"footnotes");
655 var entriesToRemove = [];
656 for (i =
0; i < noteholder.childNodes.length; i++) {
657 var entry = noteholder.childNodes[i];
658 if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute(
"class") ==
"footnote")
659 entriesToRemove.push(entry);
661 for (i =
0; i < entriesToRemove.length; i++) {
662 noteholder.removeChild(entriesToRemove[i]);
665 // Rebuild footnote entries.
666 var cont = document.getElementById(
"content");
667 var spans = cont.getElementsByTagName(
"span");
670 for (i=
0; i
<spans.length; i++) {
671 if (spans[i].className ==
"footnote") {
673 var note = spans[i].getAttribute(
"data-note");
675 // Use [\s\S] in place of . so multi-line matches work.
676 // Because JavaScript has no s (dotall) regex flag.
677 note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[
1];
679 "[<a id='_footnoteref_" + n +
"' href='#_footnote_" + n +
680 "' title='View footnote' class='footnote'>" + n +
"</a>]";
681 spans[i].setAttribute(
"data-note", note);
683 noteholder.innerHTML +=
684 "<div class='footnote' id='_footnote_" + n +
"'>" +
685 "<a href='#_footnoteref_" + n +
"' title='Return to text'>" +
686 n +
"</a>. " + note +
"</div>";
687 var id =spans[i].getAttribute(
"id");
688 if (id != null) refs[
"#"+id] = n;
692 noteholder.parentNode.removeChild(noteholder);
694 // Process footnoterefs.
695 for (i=
0; i
<spans.length; i++) {
696 if (spans[i].className ==
"footnoteref") {
697 var href = spans[i].getElementsByTagName(
"a")[
0].getAttribute(
"href");
698 href = href.match(/#.*/)[
0]; // Because IE return full URL.
701 "[<a href='#_footnote_" + n +
702 "' title='View footnote' class='footnote'>" + n +
"</a>]";
708 install: function(toclevels) {
711 function reinstall() {
712 asciidoc.footnotes();
714 asciidoc.toc(toclevels);
718 function reinstallAndRemoveTimer() {
719 clearInterval(timerId);
723 timerId = setInterval(reinstall,
500);
724 if (document.addEventListener)
725 document.addEventListener(
"DOMContentLoaded", reinstallAndRemoveTimer, false);
727 window.onload = reinstallAndRemoveTimer;
735 <body class=
"article">
737 <h1>How to revert a faulty merge
</h1>
738 <span id=
"revdate">2024-
06-
12</span>
742 <div class=
"sectionbody">
743 <div class=
"paragraph"><p>Alan
<<a href=
"mailto:alan@clueserver.org">alan@clueserver.org
</a>> said:
</p></div>
744 <div class=
"literalblock">
745 <div class=
"content">
746 <pre><code>I have a master branch. We have a branch off of that that some
747 developers are doing work on. They claim it is ready. We merge it
748 into the master branch. It breaks something so we revert the merge.
749 They make changes to the code. they get it to a point where they say
750 it is ok and we merge again.
</code></pre>
752 <div class=
"literalblock">
753 <div class=
"content">
754 <pre><code>When examined, we find that code changes made before the revert are
755 not in the master branch, but code changes after are in the master
758 <div class=
"paragraph"><p>and asked for help recovering from this situation.
</p></div>
759 <div class=
"paragraph"><p>The history immediately after the
"revert of the merge" would look like
761 <div class=
"literalblock">
762 <div class=
"content">
763 <pre><code>---o---o---o---M---x---x---W
765 ---A---B
</code></pre>
767 <div class=
"paragraph"><p>where A and B are on the side development that was not so good, M is the
768 merge that brings these premature changes into the mainline, x are changes
769 unrelated to what the side branch did and already made on the mainline,
770 and W is the
"revert of the merge M" (doesn
’t W look M upside down?).
771 IOW,
<code>"diff W^..W"</code> is similar to
<code>"diff -R M^..M"</code>.
</p></div>
772 <div class=
"paragraph"><p>Such a
"revert" of a merge can be made with:
</p></div>
773 <div class=
"literalblock">
774 <div class=
"content">
775 <pre><code>$ git revert -m
1 M
</code></pre>
777 <div class=
"paragraph"><p>After the developers of the side branch fix their mistakes, the history
778 may look like this:
</p></div>
779 <div class=
"literalblock">
780 <div class=
"content">
781 <pre><code>---o---o---o---M---x---x---W---x
783 ---A---B-------------------C---D
</code></pre>
785 <div class=
"paragraph"><p>where C and D are to fix what was broken in A and B, and you may already
786 have some other changes on the mainline after W.
</p></div>
787 <div class=
"paragraph"><p>If you merge the updated side branch (with D at its tip), none of the
788 changes made in A or B will be in the result, because they were reverted
789 by W. That is what Alan saw.
</p></div>
790 <div class=
"paragraph"><p>Linus explains the situation:
</p></div>
791 <div class=
"literalblock">
792 <div class=
"content">
793 <pre><code>Reverting a regular commit just effectively undoes what that commit
794 did, and is fairly straightforward. But reverting a merge commit also
795 undoes the _data_ that the commit changed, but it does absolutely
796 nothing to the effects on _history_ that the merge had.
</code></pre>
798 <div class=
"literalblock">
799 <div class=
"content">
800 <pre><code>So the merge will still exist, and it will still be seen as joining
801 the two branches together, and future merges will see that merge as
802 the last shared state - and the revert that reverted the merge brought
803 in will not affect that at all.
</code></pre>
805 <div class=
"literalblock">
806 <div class=
"content">
807 <pre><code>So a
"revert" undoes the data changes, but it's very much _not_ an
808 "undo" in the sense that it doesn't undo the effects of a commit on
809 the repository history.
</code></pre>
811 <div class=
"literalblock">
812 <div class=
"content">
813 <pre><code>So if you think of
"revert" as
"undo", then you're going to always
814 miss this part of reverts. Yes, it undoes the data, but no, it doesn't
815 undo history.
</code></pre>
817 <div class=
"paragraph"><p>In such a situation, you would want to first revert the previous revert,
818 which would make the history look like this:
</p></div>
819 <div class=
"literalblock">
820 <div class=
"content">
821 <pre><code>---o---o---o---M---x---x---W---x---Y
823 ---A---B-------------------C---D
</code></pre>
825 <div class=
"paragraph"><p>where Y is the revert of W. Such a
"revert of the revert" can be done
827 <div class=
"literalblock">
828 <div class=
"content">
829 <pre><code>$ git revert W
</code></pre>
831 <div class=
"paragraph"><p>This history would (ignoring possible conflicts between what W and W..Y
832 changed) be equivalent to not having W or Y at all in the history:
</p></div>
833 <div class=
"literalblock">
834 <div class=
"content">
835 <pre><code>---o---o---o---M---x---x-------x----
837 ---A---B-------------------C---D
</code></pre>
839 <div class=
"paragraph"><p>and merging the side branch again will not have conflict arising from an
840 earlier revert and revert of the revert.
</p></div>
841 <div class=
"literalblock">
842 <div class=
"content">
843 <pre><code>---o---o---o---M---x---x-------x-------*
845 ---A---B-------------------C---D
</code></pre>
847 <div class=
"paragraph"><p>Of course the changes made in C and D still can conflict with what was
848 done by any of the x, but that is just a normal merge conflict.
</p></div>
849 <div class=
"paragraph"><p>On the other hand, if the developers of the side branch discarded their
850 faulty A and B, and redone the changes on top of the updated mainline
851 after the revert, the history would have looked like this:
</p></div>
852 <div class=
"literalblock">
853 <div class=
"content">
854 <pre><code>---o---o---o---M---x---x---W---x---x
856 ---A---B A'--B'--C'
</code></pre>
858 <div class=
"paragraph"><p>If you reverted the revert in such a case as in the previous example:
</p></div>
859 <div class=
"literalblock">
860 <div class=
"content">
861 <pre><code>---o---o---o---M---x---x---W---x---x---Y---*
863 ---A---B A'--B'--C'
</code></pre>
865 <div class=
"paragraph"><p>where Y is the revert of W, A' and B' are rerolled A and B, and there may
866 also be a further fix-up C' on the side branch.
<code>"diff Y^..Y"</code> is similar
867 to
<code>"diff -R W^..W"</code> (which in turn means it is similar to
<code>"diff M^..M"</code>),
868 and
<code>"diff A'^..C'"</code> by definition would be similar but different from that,
869 because it is a rerolled series of the earlier change. There will be a
870 lot of overlapping changes that result in conflicts. So do not do
"revert
871 of revert" blindly without thinking..
</p></div>
872 <div class=
"literalblock">
873 <div class=
"content">
874 <pre><code>---o---o---o---M---x---x---W---x---x
876 ---A---B A'--B'--C'
</code></pre>
878 <div class=
"paragraph"><p>In the history with rebased side branch, W (and M) are behind the merge
879 base of the updated branch and the tip of the mainline, and they should
880 merge without the past faulty merge and its revert getting in the way.
</p></div>
881 <div class=
"paragraph"><p>To recap, these are two very different scenarios, and they want two very
882 different resolution strategies:
</p></div>
883 <div class=
"ulist"><ul>
886 If the faulty side branch was fixed by adding corrections on top, then
887 doing a revert of the previous revert would be the right thing to do.
892 If the faulty side branch whose effects were discarded by an earlier
893 revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,
894 as you seem to have interpreted), then re-merging the result without
895 doing anything else fancy would be the right thing to do.
896 (See the ADDENDUM below for how to rebuild a branch from scratch
897 without changing its original branching-off point.)
901 <div class=
"paragraph"><p>However, there are things to keep in mind when reverting a merge (and
902 reverting such a revert).
</p></div>
903 <div class=
"paragraph"><p>For example, think about what reverting a merge (and then reverting the
904 revert) does to bisectability. Ignore the fact that the revert of a revert
905 is undoing it - just think of it as a
"single commit that does a lot".
906 Because that is what it does.
</p></div>
907 <div class=
"paragraph"><p>When you have a problem you are chasing down, and you hit a
"revert this
908 merge", what you
’re hitting is essentially a single commit that contains
909 all the changes (but obviously in reverse) of all the commits that got
910 merged. So it
’s debugging hell, because now you don
’t have lots of small
911 changes that you can try to pinpoint which
<em>part
</em> of it changes.
</p></div>
912 <div class=
"paragraph"><p>But does it all work? Sure it does. You can revert a merge, and from a
913 purely technical angle, Git did it very naturally and had no real
914 troubles. It just considered it a change from
"state before merge" to
915 "state after merge", and that was it. Nothing complicated, nothing odd,
916 nothing really dangerous. Git will do it without even thinking about it.
</p></div>
917 <div class=
"paragraph"><p>So from a technical angle, there
’s nothing wrong with reverting a merge,
918 but from a workflow angle it
’s something that you generally should try to
920 <div class=
"paragraph"><p>If at all possible, for example, if you find a problem that got merged
921 into the main tree, rather than revert the merge, try
<em>really
</em> hard to
922 bisect the problem down into the branch you merged, and just fix it, or
923 try to revert the individual commit that caused it.
</p></div>
924 <div class=
"paragraph"><p>Yes, it
’s more complex, and no, it
’s not always going to work (sometimes
925 the answer is:
"oops, I really shouldn’t have merged it, because it wasn’t
926 ready yet, and I really need to undo <em>all</em> of the merge"). So then you
927 really should revert the merge, but when you want to re-do the merge, you
928 now need to do it by reverting the revert.
</p></div>
929 <div class=
"paragraph"><p>ADDENDUM
</p></div>
930 <div class=
"paragraph"><p>Sometimes you have to rewrite one of a topic branch
’s commits
<strong>and
</strong> you can
’t
931 change the topic
’s branching-off point. Consider the following situation:
</p></div>
932 <div class=
"literalblock">
933 <div class=
"content">
934 <pre><code>P---o---o---M---x---x---W---x
936 A---B---C
</code></pre>
938 <div class=
"paragraph"><p>where commit W reverted commit M because it turned out that commit B was wrong
939 and needs to be rewritten, but you need the rewritten topic to still branch
940 from commit P (perhaps P is a branching-off point for yet another branch, and
941 you want be able to merge the topic into both branches).
</p></div>
942 <div class=
"paragraph"><p>The natural thing to do in this case is to checkout the A-B-C branch and use
943 "rebase -i P" to change commit B. However this does not rewrite commit A,
944 because
"rebase -i" by default fast-forwards over any initial commits selected
945 with the
"pick" command. So you end up with this:
</p></div>
946 <div class=
"literalblock">
947 <div class=
"content">
948 <pre><code>P---o---o---M---x---x---W---x
950 A---B---C
<-- old branch
952 B'---C'
<-- naively rewritten branch
</code></pre>
954 <div class=
"paragraph"><p>To merge A-B'-C' into the mainline branch you would still have to first revert
955 commit W in order to pick up the changes in A, but then it
’s likely that the
956 changes in B' will conflict with the original B changes re-introduced by the
957 reversion of W.
</p></div>
958 <div class=
"paragraph"><p>However, you can avoid these problems if you recreate the entire branch,
959 including commit A:
</p></div>
960 <div class=
"literalblock">
961 <div class=
"content">
962 <pre><code> A'---B'---C'
<-- completely rewritten branch
964 P---o---o---M---x---x---W---x
966 A---B---C
</code></pre>
968 <div class=
"paragraph"><p>You can merge A'-B'-C' into the mainline branch without worrying about first
969 reverting W. Mainline
’s history would look like this:
</p></div>
970 <div class=
"literalblock">
971 <div class=
"content">
972 <pre><code> A'---B'---C'------------------
974 P---o---o---M---x---x---W---x---M2
976 A---B---C
</code></pre>
978 <div class=
"paragraph"><p>But if you don
’t actually need to change commit A, then you need some way to
979 recreate it as a new commit with the same changes in it. The rebase command
’s
980 --no-ff option provides a way to do this:
</p></div>
981 <div class=
"literalblock">
982 <div class=
"content">
983 <pre><code>$ git rebase [-i] --no-ff P
</code></pre>
985 <div class=
"paragraph"><p>The --no-ff option creates a new branch A'-B'-C' with all-new commits (all the
986 SHA IDs will be different) even if in the interactive case you only actually
987 modify commit B. You can then merge this new branch directly into the mainline
988 branch and be sure you
’ll get all of the branch
’s changes.
</p></div>
989 <div class=
"paragraph"><p>You can also use --no-ff in cases where you just add extra commits to the topic
990 to fix it up. Let
’s revisit the situation discussed at the start of this howto:
</p></div>
991 <div class=
"literalblock">
992 <div class=
"content">
993 <pre><code>P---o---o---M---x---x---W---x
995 A---B---C----------------D---E
<-- fixed-up topic branch
</code></pre>
997 <div class=
"paragraph"><p>At this point, you can use --no-ff to recreate the topic branch:
</p></div>
998 <div class=
"literalblock">
999 <div class=
"content">
1000 <pre><code>$ git checkout E
1001 $ git rebase --no-ff P
</code></pre>
1003 <div class=
"paragraph"><p>yielding
</p></div>
1004 <div class=
"literalblock">
1005 <div class=
"content">
1006 <pre><code> A'---B'---C'------------D'---E'
<-- recreated topic branch
1008 P---o---o---M---x---x---W---x
1010 A---B---C----------------D---E
</code></pre>
1012 <div class=
"paragraph"><p>You can merge the recreated branch into the mainline without reverting commit W,
1013 and mainline
’s history will look like this:
</p></div>
1014 <div class=
"literalblock">
1015 <div class=
"content">
1016 <pre><code> A'---B'---C'------------D'---E'
1018 P---o---o---M---x---x---W---x---M2
1020 A---B---C
</code></pre>
1025 <div id=
"footnotes"><hr /></div>
1027 <div id=
"footer-text">
1029 2024-
06-
12 15:
16:
13 PDT