[PATCH] doc: fix the 'revert a faulty merge' ASCII art tab spacing
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Oct 24, 2016, 21:54 UTC
- Message-ID
- <20161024215432.1384-1-philipoakley@iee.org>
- In-Reply-To
- <xmqq1sz9b9ex.fsf@gitster.mtv.corp.google.com>
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 --- The git-scm doc pages https://git-scm.com/docs/ does not convert this how-to document to html, rather it links to the Github text pages, which does respect the 8 space tab rule. --- Documentation/howto/revert-a-faulty-merge.txt | 16 ++++++++-------- 1 file 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
-- 2.9.0.windows.1.323.g0305acf