Skip to content

Commit 6750f62

Browse files
Philip Oakleygitster
Philip Oakley
authored andcommitted
doc: fix the 'revert a faulty merge' ASCII art tab spacing
The asciidoctor doc-tool stack does not always respect the 'tab = 8 spaces' rule expectation, particularly for the Git-for-Windows generated html pages. This follows on from the 'doc: fix merge-base ASCII art tab spacing' fix. Use just spaces within the block of the ascii art. All other *.txt ascii art containing three dashes has been checked. Asciidoctor correctly formats the other art blocks that do contain tabs. Signed-off-by: Philip Oakley <[email protected] Signed-off-by: Junio C Hamano <[email protected]>
1 parent 5dd05eb commit 6750f62

File tree

1 file changed

+8
-8
lines changed

1 file changed

+8
-8
lines changed

Documentation/howto/revert-a-faulty-merge.txt

+8-8
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,7 @@ The history immediately after the "revert of the merge" would look like
3030
this:
3131

3232
---o---o---o---M---x---x---W
33-
/
33+
/
3434
---A---B
3535

3636
where A and B are on the side development that was not so good, M is the
@@ -47,7 +47,7 @@ After the developers of the side branch fix their mistakes, the history
4747
may look like this:
4848

4949
---o---o---o---M---x---x---W---x
50-
/
50+
/
5151
---A---B-------------------C---D
5252

5353
where C and D are to fix what was broken in A and B, and you may already
@@ -81,7 +81,7 @@ In such a situation, you would want to first revert the previous revert,
8181
which would make the history look like this:
8282

8383
---o---o---o---M---x---x---W---x---Y
84-
/
84+
/
8585
---A---B-------------------C---D
8686

8787
where Y is the revert of W. Such a "revert of the revert" can be done
@@ -93,14 +93,14 @@ This history would (ignoring possible conflicts between what W and W..Y
9393
changed) be equivalent to not having W or Y at all in the history:
9494

9595
---o---o---o---M---x---x-------x----
96-
/
96+
/
9797
---A---B-------------------C---D
9898

9999
and merging the side branch again will not have conflict arising from an
100100
earlier revert and revert of the revert.
101101

102102
---o---o---o---M---x---x-------x-------*
103-
/ /
103+
/ /
104104
---A---B-------------------C---D
105105

106106
Of course the changes made in C and D still can conflict with what was
@@ -111,13 +111,13 @@ faulty A and B, and redone the changes on top of the updated mainline
111111
after the revert, the history would have looked like this:
112112

113113
---o---o---o---M---x---x---W---x---x
114-
/ \
114+
/ \
115115
---A---B A'--B'--C'
116116

117117
If you reverted the revert in such a case as in the previous example:
118118

119119
---o---o---o---M---x---x---W---x---x---Y---*
120-
/ \ /
120+
/ \ /
121121
---A---B A'--B'--C'
122122

123123
where Y is the revert of W, A' and B' are rerolled A and B, and there may
@@ -129,7 +129,7 @@ lot of overlapping changes that result in conflicts. So do not do "revert
129129
of revert" blindly without thinking..
130130

131131
---o---o---o---M---x---x---W---x---x
132-
/ \
132+
/ \
133133
---A---B A'--B'--C'
134134

135135
In the history with rebased side branch, W (and M) are behind the merge

0 commit comments

Comments
 (0)