undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'po/fix-doc-merge-base-illustration' into maint

Browse Source 
Some AsciiDoc formatter mishandles a displayed illustration with
tabs in it.  Adjust a few of them in merge-base documentation to
work around them.

* po/fix-doc-merge-base-illustration:
  doc: fix the 'revert a faulty merge' ASCII art tab spacing
  doc: fix merge-base ASCII art tab spacing
This commit is contained in:
Junio C Hamano 2016-10-28 09:01:21 -07:00
commit 311811b39f
2 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Documentation/git-merge-base.txt
View File

@ -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

16
Documentation/howto/revert-a-faulty-merge.txt
View File

@ -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