Skip to content

Commit 922a2c9

Browse files
Martin Ågrengitster
Martin Ågren
authored and
gitster
committed
git-merge-base.txt: render indentations correctly under Asciidoctor
There are several graphs in this document. For most of them, we use a single leading tab to indent the whole graph, and then we use spaces (possibly eight or more) to align things within the graph. In the larger graph, we use a different strategy: We use 1-N tabs and just a small number of spaces (<8). This is how we usually prefer to do our indenting, but Asciidoctor ends up rendering this differently from AsciiDoc. Same thing for the if-then-fi examples where the conditional code is indented by two tabs, which renders differently under AsciiDoc and Asciidoctor. Similar to 3798050 ("Documentation: render revisions correctly under Asciidoctor", 2018-05-06), use an explicit literal block to indicate that we want to keep the leading whitespace in the tables. Change not just the ones that render differently, but all of them for consistency. Because this gives us some extra indentation, we can remove the one that we have been carrying explicitly. That is, drop the first tab of indentation on each line. With AsciiDoc, this results in identical rendering before and after this commit, both for git-merge-base.1 and git-merge-base.html. A less intrusive change would be to replace tabs 2-N on each line with eight spaces. But let's follow the example set by 3798050, so that we can use our preferred way of indenting. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 2017956 commit 922a2c9

File tree

1 file changed

+57
-41
lines changed

1 file changed

+57
-41
lines changed

‎Documentation/git-merge-base.txt‎

Lines changed: 57 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -80,31 +80,37 @@ which is reachable from both 'A' and 'B' through the parent relationship.
8080

8181
For example, with this topology:
8282

83-
o---o---o---B
84-
/
85-
---o---1---o---o---o---A
83+
....
84+
o---o---o---B
85+
/
86+
---o---1---o---o---o---A
87+
....
8688

8789
the merge base between 'A' and 'B' is '1'.
8890

8991
Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the
9092
merge base between 'A' and a hypothetical commit 'M', which is a merge
9193
between 'B' and 'C'. For example, with this topology:
9294

93-
o---o---o---o---C
94-
/
95-
/ o---o---o---B
96-
/ /
97-
---2---1---o---o---o---A
95+
....
96+
o---o---o---o---C
97+
/
98+
/ o---o---o---B
99+
/ /
100+
---2---1---o---o---o---A
101+
....
98102

99103
the result of `git merge-base A B C` is '1'. This is because the
100104
equivalent topology with a merge commit 'M' between 'B' and 'C' is:
101105

102106

103-
o---o---o---o---o
104-
/ \
105-
/ o---o---o---o---M
106-
/ /
107-
---2---1---o---o---o---A
107+
....
108+
o---o---o---o---o
109+
/ \
110+
/ o---o---o---o---M
111+
/ /
112+
---2---1---o---o---o---A
113+
....
108114

109115
and the result of `git merge-base A M` is '1'. Commit '2' is also a
110116
common ancestor between 'A' and 'M', but '1' is a better common ancestor,
@@ -116,11 +122,13 @@ the best common ancestor of all commits.
116122
When the history involves criss-cross merges, there can be more than one
117123
'best' common ancestor for two commits. For example, with this topology:
118124

119-
---1---o---A
120-
\ /
121-
X
122-
/ \
123-
---2---o---o---B
125+
....
126+
---1---o---A
127+
\ /
128+
X
129+
/ \
130+
---2---o---o---B
131+
....
124132

125133
both '1' and '2' are merge-bases of A and B. Neither one is better than
126134
the other (both are 'best' merge bases). When the `--all` option is not given,
@@ -131,18 +139,22 @@ and B is (or at least used to be) to compute the merge base between
131139
A and B, and check if it is the same as A, in which case, A is an
132140
ancestor of B. You will see this idiom used often in older scripts.
133141

134-
A=$(git rev-parse --verify A)
135-
if test "$A" = "$(git merge-base A B)"
136-
then
137-
... A is an ancestor of B ...
138-
fi
142+
....
143+
A=$(git rev-parse --verify A)
144+
if test "$A" = "$(git merge-base A B)"
145+
then
146+
... A is an ancestor of B ...
147+
fi
148+
....
139149

140150
In modern git, you can say this in a more direct way:
141151

142-
if git merge-base --is-ancestor A B
143-
then
144-
... A is an ancestor of B ...
145-
fi
152+
....
153+
if git merge-base --is-ancestor A B
154+
then
155+
... A is an ancestor of B ...
156+
fi
157+
....
146158

147159
instead.
148160

@@ -154,13 +166,15 @@ topic origin/master`, the history of remote-tracking branch
154166
`origin/master` may have been rewound and rebuilt, leading to a
155167
history of this shape:
156168

157-
o---B2
158-
/
159-
---o---o---B1--o---o---o---B (origin/master)
160-
\
161-
B0
162-
\
163-
D0---D1---D (topic)
169+
....
170+
o---B2
171+
/
172+
---o---o---B1--o---o---o---B (origin/master)
173+
\
174+
B0
175+
\
176+
D0---D1---D (topic)
177+
....
164178

165179
where `origin/master` used to point at commits B0, B1, B2 and now it
166180
points at B, and your `topic` branch was started on top of it back
@@ -193,13 +207,15 @@ will find B0, and
193207
will replay D0, D1 and D on top of B to create a new history of this
194208
shape:
195209

196-
o---B2
197-
/
198-
---o---o---B1--o---o---o---B (origin/master)
199-
\ \
200-
B0 D0'--D1'--D' (topic - updated)
201-
\
202-
D0---D1---D (topic - old)
210+
....
211+
o---B2
212+
/
213+
---o---o---B1--o---o---o---B (origin/master)
214+
\ \
215+
B0 D0'--D1'--D' (topic - updated)
216+
\
217+
D0---D1---D (topic - old)
218+
....
203219

204220
A caveat is that older reflog entries in your repository may be
205221
expired by `git gc`. If B0 no longer appears in the reflog of the

0 commit comments

Comments
 (0)