manpages: italicize nongit command names (if they are in teletype font)
Some manual pages use teletype font to set command names. We change them to use italics, instead. This creates a visual distinction between names of commands and command lines that can be typed at the command line. It is also more consistent with other man pages outside Git. In this patch, the commands named are non-git commands like bash. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
42d36bb841
commit
2fd02c92db
@ -121,7 +121,7 @@ discouraged.
|
||||
--no-add::
|
||||
When applying a patch, ignore additions made by the
|
||||
patch. This can be used to extract the common part between
|
||||
two files by first running `diff` on them and applying
|
||||
two files by first running 'diff' on them and applying
|
||||
the result with this option, which would apply the
|
||||
deletion part but not addition part.
|
||||
|
||||
|
@ -115,7 +115,7 @@ This has the advantage that it will be saved in your 'CVS/Root' files and
|
||||
you don't need to worry about always setting the correct environment
|
||||
variable. SSH users restricted to 'git-shell' don't need to override the default
|
||||
with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
|
||||
'git-cvsserver' and pretends that the other end runs the real `cvs` better.
|
||||
'git-cvsserver' and pretends that the other end runs the real 'cvs' better.
|
||||
--
|
||||
2. For each repo that you want accessible from CVS you need to edit config in
|
||||
the repo and add the following section.
|
||||
@ -328,7 +328,7 @@ is left blank. But if `gitcvs.allbinary` is set to "guess", then
|
||||
the correct '-k' mode will be guessed based on the contents of
|
||||
the file.
|
||||
|
||||
For best consistency with `cvs`, it is probably best to override the
|
||||
For best consistency with 'cvs', it is probably best to override the
|
||||
defaults by setting `gitcvs.usecrlfattr` to true,
|
||||
and `gitcvs.allbinary` to "guess".
|
||||
|
||||
|
@ -87,7 +87,7 @@ sorted properly etc), but on the whole if 'git-fsck' is happy, you
|
||||
do have a valid tree.
|
||||
|
||||
Any corrupt objects you will have to find in backups or other archives
|
||||
(i.e., you can just remove them and do an `rsync` with some other site in
|
||||
(i.e., you can just remove them and do an 'rsync' with some other site in
|
||||
the hopes that somebody else has the object you have corrupted).
|
||||
|
||||
Of course, "valid tree" doesn't mean that it wasn't generated by some
|
||||
|
@ -39,8 +39,8 @@ the alternatives.
|
||||
The exit value of this program is negative on error, and the number of
|
||||
conflicts otherwise. If the merge was clean, the exit value is 0.
|
||||
|
||||
'git-merge-file' is designed to be a minimal clone of RCS `merge`; that is, it
|
||||
implements all of RCS merge's functionality which is needed by
|
||||
'git-merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it
|
||||
implements all of RCS 'merge''s functionality which is needed by
|
||||
linkgit:git[1].
|
||||
|
||||
|
||||
|
@ -47,9 +47,9 @@ A sample script called 'git-merge-one-file' is included in the
|
||||
distribution.
|
||||
|
||||
ALERT ALERT ALERT! The git "merge object order" is different from the
|
||||
RCS `merge` program merge object order. In the above ordering, the
|
||||
RCS 'merge' program merge object order. In the above ordering, the
|
||||
original is first. But the argument order to the 3-way merge program
|
||||
`merge` is to have the original in the middle. Don't ask me why.
|
||||
'merge' is to have the original in the middle. Don't ask me why.
|
||||
|
||||
Examples:
|
||||
|
||||
|
@ -45,7 +45,7 @@ will automatically invoke this command.
|
||||
This displays diffs for the current state of the resolution. It is
|
||||
useful for tracking what has changed while the user is resolving
|
||||
conflicts. Additional arguments are passed directly to the system
|
||||
`diff` command installed in PATH.
|
||||
'diff' command installed in PATH.
|
||||
|
||||
'status'::
|
||||
|
||||
|
@ -565,7 +565,7 @@ branch.
|
||||
|
||||
'git-clone' does not clone branches under the refs/remotes/ hierarchy or
|
||||
any 'git-svn' metadata, or config. So repositories created and managed with
|
||||
using 'git-svn' should use `rsync` for cloning, if cloning is to be done
|
||||
using 'git-svn' should use 'rsync' for cloning, if cloning is to be done
|
||||
at all.
|
||||
|
||||
Since 'dcommit' uses rebase internally, any git branches you 'git-push' to
|
||||
|
@ -486,7 +486,7 @@ other
|
||||
'GIT_SSH'::
|
||||
If this environment variable is set then 'git-fetch'
|
||||
and 'git-push' will use this command instead
|
||||
of `ssh` when they need to connect to a remote system.
|
||||
of 'ssh' when they need to connect to a remote system.
|
||||
The '$GIT_SSH' command will be given exactly two arguments:
|
||||
the 'username@host' (or just 'host') from the URL and the
|
||||
shell command to execute on that remote system.
|
||||
|
@ -278,7 +278,7 @@ is prefixed with a line of the form:
|
||||
|
||||
The text is called 'hunk header', and by default a line that
|
||||
begins with an alphabet, an underscore or a dollar sign is used,
|
||||
which matches what GNU `diff -p` output uses. This default
|
||||
which matches what GNU 'diff -p' output uses. This default
|
||||
selection however is not suited for some contents, and you can
|
||||
use customized pattern to make a selection.
|
||||
|
||||
@ -322,7 +322,7 @@ and other programs such as `git revert` and `git cherry-pick`.
|
||||
Set::
|
||||
|
||||
Built-in 3-way merge driver is used to merge the
|
||||
contents in a way similar to `merge` command of `RCS`
|
||||
contents in a way similar to 'merge' command of `RCS`
|
||||
suite. This is suitable for ordinary text files.
|
||||
|
||||
Unset::
|
||||
@ -426,7 +426,7 @@ Checking whitespace errors
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The `core.whitespace` configuration variable allows you to define what
|
||||
`diff` and `apply` should consider whitespace errors for all paths in
|
||||
'diff' and 'apply' should consider whitespace errors for all paths in
|
||||
the project (See linkgit:git-config[1]). This attribute gives you finer
|
||||
control per path.
|
||||
|
||||
|
@ -61,7 +61,7 @@ Initialized empty Git repository in .git/
|
||||
which is just git's way of saying that you haven't been doing anything
|
||||
strange, and that it will have created a local `.git` directory setup for
|
||||
your new project. You will now have a `.git` directory, and you can
|
||||
inspect that with `ls`. For your new empty project, it should show you
|
||||
inspect that with 'ls'. For your new empty project, it should show you
|
||||
three entries, among other things:
|
||||
|
||||
- a file called `HEAD`, that has `ref: refs/heads/master` in it.
|
||||
@ -660,7 +660,7 @@ in the new repository to make sure that the index file is up-to-date.
|
||||
|
||||
Note that the second point is true even across machines. You can
|
||||
duplicate a remote git repository with *any* regular copy mechanism, be it
|
||||
`scp`, `rsync` or `wget`.
|
||||
'scp', 'rsync' or 'wget'.
|
||||
|
||||
When copying a remote repository, you'll want to at a minimum update the
|
||||
index cache when you do this, and especially with other peoples'
|
||||
@ -1066,9 +1066,9 @@ most efficient way to exchange git objects between repositories.
|
||||
Local directory::
|
||||
`/path/to/repo.git/`
|
||||
+
|
||||
This transport is the same as SSH transport but uses `sh` to run
|
||||
This transport is the same as SSH transport but uses 'sh' to run
|
||||
both ends on the local machine instead of running other end on
|
||||
the remote machine via `ssh`.
|
||||
the remote machine via 'ssh'.
|
||||
|
||||
git Native::
|
||||
`git://remote.machine/path/to/repo.git/`
|
||||
@ -1275,8 +1275,8 @@ fatal: merge program failed
|
||||
describe those three versions, and is responsible to leave the
|
||||
merge results in the working tree.
|
||||
It is a fairly straightforward shell script, and
|
||||
eventually calls `merge` program from RCS suite to perform a
|
||||
file-level 3-way merge. In this case, `merge` detects
|
||||
eventually calls 'merge' program from RCS suite to perform a
|
||||
file-level 3-way merge. In this case, 'merge' detects
|
||||
conflicts, and the merge result with conflict marks is left in
|
||||
the working tree.. This can be seen if you run `ls-files
|
||||
--stage` again at this point:
|
||||
@ -1360,7 +1360,7 @@ program on the `$PATH`.
|
||||
[NOTE]
|
||||
Many installations of sshd do not invoke your shell as the login
|
||||
shell when you directly run programs; what this means is that if
|
||||
your login shell is `bash`, only `.bashrc` is read and not
|
||||
your login shell is 'bash', only `.bashrc` is read and not
|
||||
`.bash_profile`. As a workaround, make sure `.bashrc` sets up
|
||||
`$PATH` so that you can run 'git-receive-pack' program.
|
||||
|
||||
|
@ -34,7 +34,7 @@ $ git clone foo.com:/pub/repo.git/ my-project
|
||||
$ cd my-project
|
||||
------------------------------------------------
|
||||
|
||||
and hack away. The equivalent of `cvs update` is
|
||||
and hack away. The equivalent of 'cvs update' is
|
||||
|
||||
------------------------------------------------
|
||||
$ git pull origin
|
||||
@ -60,7 +60,7 @@ $ git push origin master
|
||||
------------------------------------------------
|
||||
|
||||
to "push" those commits to the shared repository. If someone else has
|
||||
updated the repository more recently, 'git-push', like `cvs commit`, will
|
||||
updated the repository more recently, 'git-push', like 'cvs commit', will
|
||||
complain, in which case you must pull any changes before attempting the
|
||||
push again.
|
||||
|
||||
|
@ -14,7 +14,7 @@ DESCRIPTION
|
||||
|
||||
The diff commands 'git-diff-index', 'git-diff-files', and 'git-diff-tree'
|
||||
can be told to manipulate differences they find in
|
||||
unconventional ways before showing `diff` output. The manipulation
|
||||
unconventional ways before showing 'diff' output. The manipulation
|
||||
is collectively called "diffcore transformation". This short note
|
||||
describes what they are and how to use them to produce 'diff' output
|
||||
that is easier to understand than the conventional kind.
|
||||
|
Loading…
Reference in New Issue
Block a user