From c08fd6388c0fbfc148584b45a6f721c2a4b41652 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Sat, 23 Sep 2017 01:55:26 -0400 Subject: 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
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 Signed-off-by: Junio C Hamano --- Documentation/git-read-tree.txt | 2 ++ 1 file changed, 2 insertions(+) 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, -- cgit v1.2.1