[PATCH] git-rm.txt: Fix quoting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Literal " produces typographically incorrect quotations, but "works" in
most circumstances. In the subheadings of git-rm.txt, it "works" for the
html backend but not for the docbook conversion to nroff: double "" and
spurious double spaces appear in the output.

Replace "incorrect" quotations by ``correct'' ones, and fix other
"quotations" which are really `code fragments`.

This should make git-rm.txt "-clean.

Reported-by: Jeff King <peff@xxxxxxxx>
Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>
---
We still have a lingering inconsistency for denoting code fragments.
Single backticks merely are a literal monospaced environment; html outputcolors
this, nroff does not indicate it at all. I'm staying consistent with the
surrounding text here.

 Documentation/git-rm.txt |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 71e3d9f..dd61ebd 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -89,7 +89,7 @@ the paths that have disappeared from the filesystem. However,
 depending on the use case, there are several ways that can be
 done.
 
-Using "git commit -a"
+Using ``git commit -a''
 ~~~~~~~~~~~~~~~~~~~~~
 If you intend that your next commit should record all modifications
 of tracked files in the working tree and record all removals of
@@ -98,7 +98,7 @@ files that have been removed from the working tree with `rm`
 automatically notice and record all removals.  You can also have a
 similar effect without committing by using `git add -u`.
 
-Using "git add -A"
+Using ``git add -A''
 ~~~~~~~~~~~~~~~~~~
 When accepting a new code drop for a vendor branch, you probably
 want to record both the removal of paths and additions of new paths
@@ -111,8 +111,8 @@ tree using this command:
 git ls-files -z | xargs -0 rm -f
 ----------------
 
-and then "untar" the new code in the working tree. Alternately
-you could "rsync" the changes into the working tree.
+and then `untar` the new code in the working tree. Alternately
+you could `rsync` the changes into the working tree.
 
 After that, the easiest way to record all removals, additions, and
 modifications in the working tree is:
-- 
1.7.3.2.660.g7cc83

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]