AsciiDoc replace '--' with em-dash (—) by default. em-dash
looks a lot like a single long dash and it's very confusing when
we are talking about command options.
Section 21.2.8 'Replacements' of AsciiDoc's User Guide says that a
backslash in front of double dash prevent the replacement. This
patch does just that.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
maint
Yasushi SHOJI19 years agocommitted byJunio C Hamano
@ -22,8 +22,8 @@ The git-diff-* family works by first comparing two sets of
@@ -22,8 +22,8 @@ The git-diff-* family works by first comparing two sets of
files:
- git-diff-index compares contents of a "tree" object and the
working directory (when '--cached' flag is not used) or a
"tree" object and the index file (when '--cached' flag is
working directory (when '\--cached' flag is not used) or a
"tree" object and the index file (when '\--cached' flag is
used);
- git-diff-files compares contents of the index file and the
@ -164,11 +164,11 @@ similarity score different from the default 50% by giving a
@@ -164,11 +164,11 @@ similarity score different from the default 50% by giving a
number after "-M" or "-C" option (e.g. "-M8" to tell it to use
8/10 = 80%).
Note. When the "-C" option is used with --find-copies-harder
Note. When the "-C" option is used with `\--find-copies-harder`
option, git-diff-\* commands feed unmodified filepairs to
diffcore mechanism as well as modified ones. This lets the copy
detector consider unmodified files as copy source candidates at
the expense of making it slower. Without --find-copies-harder,
the expense of making it slower. Without `\--find-copies-harder`,
git-diff-\* commands can detect copies only if the file that was
copied happened to have been modified in the same changeset.
This transformation is used to find filepairs that represent
changes that touch a specified string, and is controlled by the
-S option and the --pickaxe-all option to the git-diff-*
-S option and the `\--pickaxe-all` option to the git-diff-*
commands.
When diffcore-pickaxe is in use, it checks if there are
@ -229,9 +229,9 @@ whose "result" side does not. Such a filepair represents "the
@@ -229,9 +229,9 @@ whose "result" side does not. Such a filepair represents "the
string appeared in this changeset". It also checks for the
opposite case that loses the specified string.
When --pickaxe-all is not in effect, diffcore-pickaxe leaves
When `\--pickaxe-all` is not in effect, diffcore-pickaxe leaves
only such filepairs that touches the specified string in its
output. When --pickaxe-all is used, diffcore-pickaxe leaves all
output. When `\--pickaxe-all` is used, diffcore-pickaxe leaves all
filepairs intact if there is such a filepair, or makes the
output empty otherwise. The latter behaviour is designed to
make reviewing of the changes in the context of the whole
@ -828,7 +828,7 @@ which will very loudly warn you that you're now committing a merge
@@ -828,7 +828,7 @@ which will very loudly warn you that you're now committing a merge
(which is correct, so never mind), and you can write a small merge
message about your adventures in git-merge-land.
After you're done, start up `gitk --all` to see graphically what the
After you're done, start up `gitk \--all` to see graphically what the
history looks like. Notice that `mybranch` still exists, and you can
switch to it, and continue to work with it if you want to. The
`mybranch` branch will not contain the merge, but next time you merge it
@ -883,7 +883,7 @@ not actually do a merge. Instead, it just updated the top of
@@ -883,7 +883,7 @@ not actually do a merge. Instead, it just updated the top of
the tree of your branch to that of the `master` branch. This is
often called 'fast forward' merge.
You can run `gitk --all` again to see how the commit ancestry
You can run `gitk \--all` again to see how the commit ancestry
looks like, or run `show-branch`, which tells you this.