From 5dd05ebf6f963a7844cc8208b6c8170698aec222 Mon Sep 17 00:00:00 2001 From: Philip Oakley Date: Fri, 21 Oct 2016 00:40:09 +0100 Subject: doc: fix merge-base ASCII art tab spacing The doc-tool stack does not always respect the 'tab = 8 spaces' rule, particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base and the Git generated html pages. Use just spaces within the block of the ascii art. Noticed when reviewing Junio's suggested update to `git merge-base` https://public-inbox.org/git/xmqqmvi2sj8f.fsf@gitster.mtv.corp.google.com/T/#u Signed-off-by: Philip Oakley Signed-off-by: Junio C Hamano --- Documentation/git-merge-base.txt | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index 808426faac..b968b64c38 100644 --- a/Documentation/git-merge-base.txt +++ b/Documentation/git-merge-base.txt @@ -80,8 +80,8 @@ which is reachable from both 'A' and 'B' through the parent relationship. For example, with this topology: - o---o---o---B - / + o---o---o---B + / ---o---1---o---o---o---A the merge base between 'A' and 'B' is '1'. @@ -116,11 +116,11 @@ the best common ancestor of all commits. When the history involves criss-cross merges, there can be more than one 'best' common ancestor for two commits. For example, with this topology: - ---1---o---A - \ / - X - / \ - ---2---o---o---B + ---1---o---A + \ / + X + / \ + ---2---o---o---B both '1' and '2' are merge-bases of A and B. Neither one is better than the other (both are 'best' merge bases). When the `--all` option is not given, @@ -154,13 +154,13 @@ topic origin/master`, the history of remote-tracking branch `origin/master` may have been rewound and rebuilt, leading to a history of this shape: - o---B1 - / + o---B1 + / ---o---o---B2--o---o---o---B (origin/master) - \ - B3 - \ - Derived (topic) + \ + B3 + \ + Derived (topic) where `origin/master` used to point at commits B3, B2, B1 and now it points at B, and your `topic` branch was started on top of it back -- cgit v1.2.3 From 6750f6269917969dbb191406c3ed31d5a75a9edd Mon Sep 17 00:00:00 2001 From: Philip Oakley Date: Mon, 24 Oct 2016 22:54:32 +0100 Subject: 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 --- 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 462255ed5d..19f59cc888 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 -- cgit v1.2.3