summaryrefslogtreecommitdiff
path: root/Documentation/howto
diff options
context:
space:
mode:
authorPhilip Oakley <philipoakley@iee.org>2016-10-24 21:54:32 (GMT)
committerJunio C Hamano <gitster@pobox.com>2016-10-25 01:09:46 (GMT)
commit6750f6269917969dbb191406c3ed31d5a75a9edd (patch)
tree2e9f539e07f2132fe51f5c0776c106f940d4692c /Documentation/howto
parent5dd05ebf6f963a7844cc8208b6c8170698aec222 (diff)
downloadgit-6750f6269917969dbb191406c3ed31d5a75a9edd.zip
git-6750f6269917969dbb191406c3ed31d5a75a9edd.tar.gz
git-6750f6269917969dbb191406c3ed31d5a75a9edd.tar.bz2
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 <philipoakley@iee.org Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/howto')
-rw-r--r--Documentation/howto/revert-a-faulty-merge.txt16
1 files changed, 8 insertions, 8 deletions
diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt
index 462255e..19f59cc 100644
--- a/Documentation/howto/revert-a-faulty-merge.txt
+++ b/Documentation/howto/revert-a-faulty-merge.txt
@@ -30,7 +30,7 @@ The history immediately after the "revert of the merge" would look like
this:
---o---o---o---M---x---x---W
- /
+ /
---A---B
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
may look like this:
---o---o---o---M---x---x---W---x
- /
+ /
---A---B-------------------C---D
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,
which would make the history look like this:
---o---o---o---M---x---x---W---x---Y
- /
+ /
---A---B-------------------C---D
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
changed) be equivalent to not having W or Y at all in the history:
---o---o---o---M---x---x-------x----
- /
+ /
---A---B-------------------C---D
and merging the side branch again will not have conflict arising from an
earlier revert and revert of the revert.
---o---o---o---M---x---x-------x-------*
- / /
+ / /
---A---B-------------------C---D
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
after the revert, the history would have looked like this:
---o---o---o---M---x---x---W---x---x
- / \
+ / \
---A---B A'--B'--C'
If you reverted the revert in such a case as in the previous example:
---o---o---o---M---x---x---W---x---x---Y---*
- / \ /
+ / \ /
---A---B A'--B'--C'
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
of revert" blindly without thinking..
---o---o---o---M---x---x---W---x---x
- / \
+ / \
---A---B A'--B'--C'
In the history with rebased side branch, W (and M) are behind the merge