diff options
| author |  Jeff King <peff@peff.net> | 2017-09-23 01:55:26 -0400 |
|---|---|---|
| committer |  Junio C Hamano <gitster@pobox.com> | 2017-09-24 10:09:45 +0900 |
| commit | c08fd6388c0fbfc148584b45a6f721c2a4b41652 (patch) | |
| tree | f9ae1e0b64b4ff3483afb2b6b03a3a9e32c6b37d | |
| parent | Git 2.12.4 (diff) | |
| download | tgif-c08fd6388c0fbfc148584b45a6f721c2a4b41652.tar.xz | |
doc: put literal block delimiter around table
The git-read-tree manpage has a table that is meant to
be shown with its spacing exactly as it is in the source. We
mark it as a "literal paragraph" by indenting each line by
at least one space. This renders OK with asciidoc for both
the HTML and manpage versions.
But there are two problems when we render it with
asciidoctor.
The first is that some lines mix tabs and spaces. Even if
asciidoctor is correctly configured for 8-space tabs, it
seems to handle this case differently, soaking up some of
the initial literal-paragraph spaces and mis-aligning the
table text.
The second problem is that the table uses blank lines to
group rows. But as blank lines separate paragraphs in
asciidoc, this actually means that each chunk of the table
is rendered in its own pre-formatted <div> block. This
happens even with vanilla asciidoc, but there's no visible
result because the literal paragraphs aren't styled in any
special way. But with asciidoctor (or at least the styles
used on git-scm.com), literal paragraphs are styled with a
different background. This breaks the table into a visually
distracting sequence of chunks.
We can fix both by adding a literal-paragraph block
delimiter. That turns the whole table into a single block
(for both implementations) and causes asciidoctor to render
the indentation as it is in the source.
Reported-at: https://github.com/git/git-scm.com/issues/1023
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
| -rw-r--r-- | Documentation/git-read-tree.txt | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index fa1d557e5b..665bf9f25b 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -173,6 +173,7 @@ Here are the "carry forward" rules, where "I" denotes the index, "clean" means that index and work tree coincide, and "exists"/"nothing" refer to the presence of a path in the specified commit: +.... I H M Result ------------------------------------------------------- 0 nothing nothing nothing (does not happen) @@ -211,6 +212,7 @@ refer to the presence of a path in the specified commit: 19 no no yes exists exists keep index 20 yes yes no exists exists use M 21 no yes no exists exists fail +.... In all "keep index" cases, the index entry stays as in the original index file. If the entry is not up to date, |