From 0ee7a9afa1be9ad02b1b82da08359a5ff4c4a9b7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20=C3=85gren?= Date: Sun, 16 Dec 2018 15:28:57 +0100 Subject: [PATCH 1/3] git-column.txt: fix section header MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We have too few dashes under "Examples", which causes Asciidoctor to not pick it up as a section header. Instead, it thinks we are starting a code listing block, which ends up containing the remainder of the document. The result is quite ugly. Make sure we have as many dashes as we have characters in "Examples". Asciidoc renders identically before and after this patch, both man-page and html. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano --- Documentation/git-column.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt index 763afabb6d..f58e9c43e6 100644 --- a/Documentation/git-column.txt +++ b/Documentation/git-column.txt @@ -47,7 +47,7 @@ OPTIONS The number of spaces between columns. One space by default. EXAMPLES ------- +-------- Format data by columns: ------------ From ad1f243ad9e8740093abbcd93a3b0683dcd15107 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20=C3=85gren?= Date: Sun, 16 Dec 2018 15:28:58 +0100 Subject: [PATCH 2/3] Documentation: do not nest open blocks MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It appears we try to nest open blocks, but that does not work well with Asciidoctor, which fails to indent the inner blocks. As a result, they do not visually seem to relate (as much) to the preceding paragraph as they should. Drop the outer blocks to fix the rendering of the inner ones. Asciidoc renders identically before and after this patch, both man-pages and html. This also makes Asciidoctor stop rendering a literal '+' before "Under --pretty=oneline ..." in the manuals for git-log and git-rev-list. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano --- Documentation/git-init.txt | 4 ---- Documentation/rev-list-options.txt | 4 ---- 2 files changed, 8 deletions(-) diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 3c5a67fb96..057076ca38 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -38,8 +38,6 @@ the repository to another place if --separate-git-dir is given). OPTIONS ------- --- - -q:: --quiet:: @@ -111,8 +109,6 @@ into it. If you provide a 'directory', the command is run inside it. If this directory does not exist, it will be created. --- - TEMPLATE DIRECTORY ------------------ diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index bab5f50b17..98b538bc77 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -13,8 +13,6 @@ has a line that matches ``), unless otherwise noted. Note that these are applied before commit ordering and formatting options, such as `--reverse`. --- - -:: -n :: --max-count=:: @@ -308,8 +306,6 @@ ifdef::git-rev-list[] `
` text will be printed with each progress update. endif::git-rev-list[] --- - History Simplification ~~~~~~~~~~~~~~~~~~~~~~ From b62eb1d2f4d19bcc42945eb6e2d231da1dfdcb50 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20=C3=85gren?= Date: Sun, 16 Dec 2018 15:28:59 +0100 Subject: [PATCH 3/3] git-status.txt: render tables correctly under Asciidoctor MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Asciidoctor removes the indentation of each line in these tables, so the last lines of each table have a completely broken alignment. Similar to 379805051d ("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. Because this gives us some extra indentation, we can remove the one that we have been carrying explicitly. That is, drop the first four spaces of indentation on each line. With Asciidoc (8.6.10), this results in identical rendering before and after this commit, both for git-status.1 and git-status.html. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano --- Documentation/git-status.txt | 162 ++++++++++++++++++----------------- 1 file changed, 85 insertions(+), 77 deletions(-) diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index d9f422d560..861d821d7f 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -197,31 +197,33 @@ codes can be interpreted as follows: Ignored files are not listed, unless `--ignored` option is in effect, in which case `XY` are `!!`. - X Y Meaning - ------------------------------------------------- - [AMD] not updated - M [ MD] updated in index - A [ MD] added to index - D deleted from index - R [ MD] renamed in index - C [ MD] copied in index - [MARC] index and work tree matches - [ MARC] M work tree changed since index - [ MARC] D deleted in work tree - [ D] R renamed in work tree - [ D] C copied in work tree - ------------------------------------------------- - D D unmerged, both deleted - A U unmerged, added by us - U D unmerged, deleted by them - U A unmerged, added by them - D U unmerged, deleted by us - A A unmerged, both added - U U unmerged, both modified - ------------------------------------------------- - ? ? untracked - ! ! ignored - ------------------------------------------------- +.... +X Y Meaning +------------------------------------------------- + [AMD] not updated +M [ MD] updated in index +A [ MD] added to index +D deleted from index +R [ MD] renamed in index +C [ MD] copied in index +[MARC] index and work tree matches +[ MARC] M work tree changed since index +[ MARC] D deleted in work tree +[ D] R renamed in work tree +[ D] C copied in work tree +------------------------------------------------- +D D unmerged, both deleted +A U unmerged, added by us +U D unmerged, deleted by them +U A unmerged, added by them +D U unmerged, deleted by us +A A unmerged, both added +U U unmerged, both modified +------------------------------------------------- +? ? untracked +! ! ignored +------------------------------------------------- +.... Submodules have more state and instead report M the submodule has a different HEAD than @@ -281,14 +283,16 @@ don't recognize. If `--branch` is given, a series of header lines are printed with information about the current branch. - Line Notes - ------------------------------------------------------------ - # branch.oid | (initial) Current commit. - # branch.head | (detached) Current branch. - # branch.upstream If upstream is set. - # branch.ab + - If upstream is set and - the commit is present. - ------------------------------------------------------------ +.... +Line Notes +------------------------------------------------------------ +# branch.oid | (initial) Current commit. +# branch.head | (detached) Current branch. +# branch.upstream If upstream is set. +# branch.ab + - If upstream is set and + the commit is present. +------------------------------------------------------------ +.... ### Changed Tracked Entries @@ -306,56 +310,60 @@ Renamed or copied entries have the following format: 2 - Field Meaning - -------------------------------------------------------- - A 2 character field containing the staged and - unstaged XY values described in the short format, - with unchanged indicated by a "." rather than - a space. - A 4 character field describing the submodule state. - "N..." when the entry is not a submodule. - "S" when the entry is a submodule. - is "C" if the commit changed; otherwise ".". - is "M" if it has tracked changes; otherwise ".". - is "U" if there are untracked changes; otherwise ".". - The octal file mode in HEAD. - The octal file mode in the index. - The octal file mode in the worktree. - The object name in HEAD. - The object name in the index. - The rename or copy score (denoting the percentage - of similarity between the source and target of the - move or copy). For example "R100" or "C75". - The pathname. In a renamed/copied entry, this - is the target path. - When the `-z` option is used, the 2 pathnames are separated - with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09) - byte separates them. - The pathname in the commit at HEAD or in the index. - This is only present in a renamed/copied entry, and - tells where the renamed/copied contents came from. - -------------------------------------------------------- +.... +Field Meaning +-------------------------------------------------------- + A 2 character field containing the staged and + unstaged XY values described in the short format, + with unchanged indicated by a "." rather than + a space. + A 4 character field describing the submodule state. + "N..." when the entry is not a submodule. + "S" when the entry is a submodule. + is "C" if the commit changed; otherwise ".". + is "M" if it has tracked changes; otherwise ".". + is "U" if there are untracked changes; otherwise ".". + The octal file mode in HEAD. + The octal file mode in the index. + The octal file mode in the worktree. + The object name in HEAD. + The object name in the index. + The rename or copy score (denoting the percentage + of similarity between the source and target of the + move or copy). For example "R100" or "C75". + The pathname. In a renamed/copied entry, this + is the target path. + When the `-z` option is used, the 2 pathnames are separated + with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09) + byte separates them. + The pathname in the commit at HEAD or in the index. + This is only present in a renamed/copied entry, and + tells where the renamed/copied contents came from. +-------------------------------------------------------- +.... Unmerged entries have the following format; the first character is a "u" to distinguish from ordinary changed entries. u

- Field Meaning - -------------------------------------------------------- - A 2 character field describing the conflict type - as described in the short format. - A 4 character field describing the submodule state - as described above. - The octal file mode in stage 1. - The octal file mode in stage 2. - The octal file mode in stage 3. - The octal file mode in the worktree. -

The object name in stage 1. -

The object name in stage 2. -

The object name in stage 3. - The pathname. - -------------------------------------------------------- +.... +Field Meaning +-------------------------------------------------------- + A 2 character field describing the conflict type + as described in the short format. + A 4 character field describing the submodule state + as described above. + The octal file mode in stage 1. + The octal file mode in stage 2. + The octal file mode in stage 3. + The octal file mode in the worktree. +

The object name in stage 1. +

The object name in stage 2. +

The object name in stage 3. + The pathname. +-------------------------------------------------------- +.... ### Other Items