Commit 0b444cdb authored by Thomas Rast's avatar Thomas Rast

Documentation: spell 'git cmd' without dash throughout

The documentation was quite inconsistent when spelling 'git cmd' if it
only refers to the program, not to some specific invocation syntax:
both 'git-cmd' and 'git cmd' spellings exist.

The current trend goes towards dashless forms, and there is precedent
in 647ac702 (git-svn.txt: stop using dash-form of commands.,
2009-07-07) to actively eliminate the dashed variants.

Replace 'git-cmd' with 'git cmd' throughout, except where git-shell,
git-cvsserver, git-upload-pack, git-receive-pack, and
git-upload-archive are concerned, because those really live in the
$PATH.
parent ca768288
......@@ -64,7 +64,7 @@ The values following the equals sign in variable assign are all either
a string, an integer, or a boolean. Boolean values may be given as yes/no,
0/1, true/false or on/off. Case is not significant in boolean values, when
converting value to the canonical form using '--bool' type specifier;
'git-config' will ensure that the output is "true" or "false".
'git config' will ensure that the output is "true" or "false".
String values may be entirely or partially enclosed in double quotes.
You need to enclose variable values in double quotes if you want to
......@@ -442,8 +442,8 @@ core.pager::
core.whitespace::
A comma separated list of common whitespace problems to
notice. 'git-diff' will use `color.diff.whitespace` to
highlight them, and 'git-apply --whitespace=error' will
notice. 'git diff' will use `color.diff.whitespace` to
highlight them, and 'git apply --whitespace=error' will
consider them as errors. You can prefix `-` to disable
any of them (e.g. `-trailing-space`):
+
......@@ -503,7 +503,7 @@ This setting defaults to "refs/notes/commits", and can be overridden by
the `GIT_NOTES_REF` environment variable.
add.ignore-errors::
Tells 'git-add' to continue adding files when some files cannot be
Tells 'git add' to continue adding files when some files cannot be
added due to indexing errors. Equivalent to the '--ignore-errors'
option of linkgit:git-add[1].
......@@ -525,19 +525,19 @@ executed from the top-level directory of a repository, which may
not necessarily be the current directory.
apply.ignorewhitespace::
When set to 'change', tells 'git-apply' to ignore changes in
When set to 'change', tells 'git apply' to ignore changes in
whitespace, in the same way as the '--ignore-space-change'
option.
When set to one of: no, none, never, false tells 'git-apply' to
When set to one of: no, none, never, false tells 'git apply' to
respect all whitespace differences.
See linkgit:git-apply[1].
apply.whitespace::
Tells 'git-apply' how to handle whitespaces, in the same way
Tells 'git apply' how to handle whitespaces, in the same way
as the '--whitespace' option. See linkgit:git-apply[1].
branch.autosetupmerge::
Tells 'git-branch' and 'git-checkout' to setup new branches
Tells 'git branch' and 'git checkout' to setup new branches
so that linkgit:git-pull[1] will appropriately merge from the
starting point branch. Note that even if this option is not set,
this behavior can be chosen per-branch using the `--track`
......@@ -548,7 +548,7 @@ branch.autosetupmerge::
branch. This option defaults to true.
branch.autosetuprebase::
When a new branch is created with 'git-branch' or 'git-checkout'
When a new branch is created with 'git branch' or 'git checkout'
that tracks another branch, this variable tells git to set
up pull to rebase instead of merge (see "branch.<name>.rebase").
When `never`, rebase is never automatically set to true.
......@@ -563,24 +563,24 @@ branch.autosetuprebase::
This option defaults to never.
branch.<name>.remote::
When in branch <name>, it tells 'git-fetch' and 'git-push' which
When in branch <name>, it tells 'git fetch' and 'git push' which
remote to fetch from/push to. It defaults to `origin` if no remote is
configured. `origin` is also used if you are not on any branch.
branch.<name>.merge::
Defines, together with branch.<name>.remote, the upstream branch
for the given branch. It tells 'git-fetch'/'git-pull' which
branch to merge and can also affect 'git-push' (see push.default).
When in branch <name>, it tells 'git-fetch' the default
for the given branch. It tells 'git fetch'/'git pull' which
branch to merge and can also affect 'git push' (see push.default).
When in branch <name>, it tells 'git fetch' the default
refspec to be marked for merging in FETCH_HEAD. The value is
handled like the remote part of a refspec, and must match a
ref which is fetched from the remote given by
"branch.<name>.remote".
The merge information is used by 'git-pull' (which at first calls
'git-fetch') to lookup the default branch for merging. Without
this option, 'git-pull' defaults to merge the first refspec fetched.
The merge information is used by 'git pull' (which at first calls
'git fetch') to lookup the default branch for merging. Without
this option, 'git pull' defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.
If you wish to setup 'git-pull' so that it merges into <name> from
If you wish to setup 'git pull' so that it merges into <name> from
another branch in the local repository, you can point
branch.<name>.merge to the desired branch, and use the special setting
`.` (a period) for branch.<name>.remote.
......@@ -673,7 +673,7 @@ color.interactive::
colors only when the output is to the terminal. Defaults to false.
color.interactive.<slot>::
Use customized color for 'git-add --interactive'
Use customized color for 'git add --interactive'
output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
four distinct types of normal output from interactive
commands. The values of these variables may be specified as
......@@ -718,14 +718,14 @@ commit.template::
specified user's home directory.
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
When using 'git diff' to compare with work tree
files, do not consider stat-only change as changed.
Instead, silently run `git update-index --refresh` to
update the cached stat information for paths whose
contents in the work tree match the contents in the
index. This option defaults to true. Note that this
affects only 'git-diff' Porcelain, and not lower level
'diff' commands, such as 'git-diff-files'.
affects only 'git diff' Porcelain, and not lower level
'diff' commands, such as 'git diff-files'.
diff.external::
If this config variable is set, diff generation is not
......@@ -737,7 +737,7 @@ diff.external::
your files, you might want to use linkgit:gitattributes[5] instead.
diff.mnemonicprefix::
If set, 'git-diff' uses a prefix pair that is different from the
If set, 'git diff' uses a prefix pair that is different from the
standard "a/" and "b/" depending on what is being compared. When
this configuration is in effect, reverse diff output also swaps
the order of the prefixes:
......@@ -754,7 +754,7 @@ diff.mnemonicprefix::
diff.renameLimit::
The number of files to consider when performing the copy/rename
detection; equivalent to the 'git-diff' option '-l'.
detection; equivalent to the 'git diff' option '-l'.
diff.renames::
Tells git to detect renames. If set to any boolean value, it
......@@ -840,7 +840,7 @@ format.pretty::
linkgit:git-whatchanged[1].
format.thread::
The default threading style for 'git-format-patch'. Can be
The default threading style for 'git format-patch'. Can be
either a boolean value, `shallow` or `deep`. `shallow`
threading makes every mail a reply to the head of the series,
where the head is chosen from the cover letter, the
......@@ -858,7 +858,7 @@ format.signoff::
gc.aggressiveWindow::
The window size parameter used in the delta compression
algorithm used by 'git-gc --aggressive'. This defaults
algorithm used by 'git gc --aggressive'. This defaults
to 10.
gc.auto::
......@@ -875,39 +875,39 @@ gc.autopacklimit::
default value is 50. Setting this to 0 disables it.
gc.packrefs::
'git-gc' does not run `git pack-refs` in a bare repository by
'git gc' does not run `git pack-refs` in a bare repository by
default so that older dumb-transport clients can still fetch
from the repository. Setting this to `true` lets 'git-gc'
from the repository. Setting this to `true` lets 'git gc'
to run `git pack-refs`. Setting this to `false` tells
'git-gc' never to run `git pack-refs`. The default setting is
'git gc' never to run `git pack-refs`. The default setting is
`notbare`. Enable it only when you know you do not have to
support such clients. The default setting will change to `true`
at some stage, and setting this to `false` will continue to
prevent `git pack-refs` from being run from 'git-gc'.
prevent `git pack-refs` from being run from 'git gc'.
gc.pruneexpire::
When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.
Override the grace period with this config variable. The value
"now" may be used to disable this grace period and always prune
unreachable objects immediately.
gc.reflogexpire::
'git-reflog expire' removes reflog entries older than
'git reflog expire' removes reflog entries older than
this time; defaults to 90 days.
gc.reflogexpireunreachable::
'git-reflog expire' removes reflog entries older than
'git reflog expire' removes reflog entries older than
this time and are not reachable from the current tip;
defaults to 30 days.
gc.rerereresolved::
Records of conflicted merge you resolved earlier are
kept for this many days when 'git-rerere gc' is run.
kept for this many days when 'git rerere gc' is run.
The default is 60 days. See linkgit:git-rerere[1].
gc.rerereunresolved::
Records of conflicted merge you have not resolved are
kept for this many days when 'git-rerere gc' is run.
kept for this many days when 'git rerere gc' is run.
The default is 15 days. See linkgit:git-rerere[1].
gitcvs.commitmsgannotation::
......@@ -1168,7 +1168,7 @@ i18n.commitEncoding::
i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
running 'git-log' and friends.
running 'git log' and friends.
imap::
The configuration variables in the 'imap' section are described
......@@ -1202,7 +1202,7 @@ interactive.singlekey::
log.date::
Set default date-time mode for the log command. Setting log.date
value is similar to using 'git-log'\'s --date option. The value is one of the
value is similar to using 'git log'\'s --date option. The value is one of the
following alternatives: {relative,local,default,iso,rfc,short}.
See linkgit:git-log[1].
......
......@@ -19,7 +19,7 @@ endif::git-pull[]
-f::
--force::
When 'git-fetch' is used with `<rbranch>:<lbranch>`
When 'git fetch' is used with `<rbranch>:<lbranch>`
refspec, it refuses to update the local branch
`<lbranch>` unless the remote branch `<rbranch>` it
fetches is a descendant of `<lbranch>`. This option
......@@ -61,16 +61,16 @@ endif::git-pull[]
-u::
--update-head-ok::
By default 'git-fetch' refuses to update the head which
By default 'git fetch' refuses to update the head which
corresponds to the current branch. This flag disables the
check. This is purely for the internal use for 'git-pull'
to communicate with 'git-fetch', and unless you are
check. This is purely for the internal use for 'git pull'
to communicate with 'git fetch', and unless you are
implementing your own Porcelain you are not supposed to
use it.
--upload-pack <upload-pack>::
When given, and the repository to fetch from is handled
by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
by 'git fetch-pack', '--exec=<upload-pack>' is passed to
the command to specify non-default path for the command
run on the other end.
......
......@@ -37,7 +37,7 @@ OPTIONS
-k::
--keep::
Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
-c::
--scissors::
......@@ -53,7 +53,7 @@ OPTIONS
-u::
--utf8::
Pass `-u` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
Pass `-u` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
The proposed commit log message taken from the e-mail
is re-coded into UTF-8 encoding (configuration variable
`i18n.commitencoding` can be used to specify project's
......@@ -63,7 +63,7 @@ This was optional in prior versions of git, but now it is the
default. You can use `--no-utf8` to override this.
--no-utf8::
Pass `-n` flag to 'git-mailinfo' (see
Pass `-n` flag to 'git mailinfo' (see
linkgit:git-mailinfo[1]).
-3::
......@@ -81,7 +81,7 @@ default. You can use `--no-utf8` to override this.
-p<n>::
--directory=<dir>::
--reject::
These flags are passed to the 'git-apply' (see linkgit:git-apply[1])
These flags are passed to the 'git apply' (see linkgit:git-apply[1])
program that applies
the patch.
......@@ -121,7 +121,7 @@ default. You can use `--no-utf8` to override this.
to the screen before exiting. This overrides the
standard message informing you to use `--resolved`
or `--skip` to handle the failure. This is solely
for internal use between 'git-rebase' and 'git-am'.
for internal use between 'git rebase' and 'git am'.
--abort::
Restore the original branch and abort the patching operation.
......
......@@ -69,7 +69,7 @@ OPTIONS
without using the working tree. This implies `--index`.
--build-fake-ancestor=<file>::
Newer 'git-diff' output has embedded 'index information'
Newer 'git diff' output has embedded 'index information'
for each blob to help identify the original version that
the patch applies to. When this flag is given, and if
the original versions of the blobs are available locally,
......@@ -83,7 +83,7 @@ the information is read from the current index instead.
Apply the patch in reverse.
--reject::
For atomicity, 'git-apply' by default fails the whole patch and
For atomicity, 'git apply' by default fails the whole patch and
does not touch the working tree when some of the hunks
do not apply. This option makes it apply
the parts of the patch that are applicable, and leave the
......@@ -109,7 +109,7 @@ any of those replacements occurred.
ever ignored.
--unidiff-zero::
By default, 'git-apply' expects that the patch being
By default, 'git apply' expects that the patch being
applied is a unified diff with at least one line of context.
This provides good safety measures, but breaks down when
applying a diff generated with `--unified=0`. To bypass these
......@@ -120,7 +120,7 @@ discouraged.
--apply::
If you use any of the options marked "Turns off
'apply'" above, 'git-apply' reads and outputs the
'apply'" above, 'git apply' reads and outputs the
requested information without actually applying the
patch. Give this flag after those flags to also apply
the patch.
......@@ -229,7 +229,7 @@ apply.whitespace::
Submodules
----------
If the patch contains any changes to submodules then 'git-apply'
If the patch contains any changes to submodules then 'git apply'
treats these changes as follows.
If `--index` is specified (explicitly or implicitly), then the submodule
......
......@@ -29,17 +29,17 @@ branches that have different roots, it will refuse to run. In that case,
edit your <archive/branch> parameters to define clearly the scope of the
import.
'git-archimport' uses `tla` extensively in the background to access the
'git archimport' uses `tla` extensively in the background to access the
Arch repository.
Make sure you have a recent version of `tla` available in the path. `tla` must
know about the repositories you pass to 'git-archimport'.
know about the repositories you pass to 'git archimport'.
For the initial import, 'git-archimport' expects to find itself in an empty
For the initial import, 'git archimport' expects to find itself in an empty
directory. To follow the development of a project that uses Arch, rerun
'git-archimport' with the same parameters as the initial import to perform
'git archimport' with the same parameters as the initial import to perform
incremental imports.
While 'git-archimport' will try to create sensible branch names for the
While 'git archimport' will try to create sensible branch names for the
archives that it imports, it is also possible to specify git branch names
manually. To do so, write a git branch name after each <archive/branch>
parameter, separated by a colon. This way, you can shorten the Arch
......@@ -84,7 +84,7 @@ OPTIONS
-o::
Use this for compatibility with old-style branch names used by
earlier versions of 'git-archimport'. Old-style branch names
earlier versions of 'git archimport'. Old-style branch names
were category--branch, whereas new-style branch names are
archive,category--branch--version. In both cases, names given
on the command-line will override the automatically-generated
......
......@@ -21,13 +21,13 @@ structure for the named tree, and writes it out to the standard
output. If <prefix> is specified it is
prepended to the filenames in the archive.
'git-archive' behaves differently when given a tree ID versus when
'git archive' behaves differently when given a tree ID versus when
given a commit ID or tag ID. In the first case the current time is
used as the modification time of each file in the archive. In the latter
case the commit time as recorded in the referenced commit object is
used instead. Additionally the commit ID is stored in a global
extended pax header if the tar format is used; it can be extracted
using 'git-get-tar-commit-id'. In ZIP files it is stored as a file
using 'git get-tar-commit-id'. In ZIP files it is stored as a file
comment.
OPTIONS
......
......@@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.
The command can also limit the range of lines annotated.
The report does not tell you anything about lines which have been deleted or
replaced; you need to use a tool such as 'git-diff' or the "pickaxe"
replaced; you need to use a tool such as 'git diff' or the "pickaxe"
interface briefly mentioned in the following paragraph.
Apart from supporting file annotation, git also supports searching the
......@@ -49,7 +49,7 @@ include::blame-options.txt[]
file (see `-M`). The first number listed is the score.
This is the number of alphanumeric characters detected
as having been moved between or within files. This must be above
a certain threshold for 'git-blame' to consider those lines
a certain threshold for 'git blame' to consider those lines
of code to have been moved.
-f::
......@@ -100,7 +100,7 @@ header elements later.
SPECIFYING RANGES
-----------------
Unlike 'git-blame' and 'git-annotate' in older versions of git, the extent
Unlike 'git blame' and 'git annotate' in older versions of git, the extent
of the annotation can be limited to both line ranges and revision
ranges. When you are interested in finding the origin for
lines 40-60 for file `foo`, you can use the `-L` option like so
......@@ -118,7 +118,7 @@ which limits the annotation to the body of the `hello` subroutine.
When you are not interested in changes older than version
v2.6.18, or changes older than 3 weeks, you can use revision
range specifiers similar to 'git-rev-list':
range specifiers similar to 'git rev-list':
git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo
......
......@@ -38,7 +38,7 @@ working tree to it; use "git checkout <newbranch>" to switch to the
new branch.
When a local branch is started off a remote branch, git sets up the
branch so that 'git-pull' will appropriately merge from
branch so that 'git pull' will appropriately merge from
the remote branch. This behavior may be changed via the global
`branch.autosetupmerge` configuration flag. That setting can be
overridden by using the `--track` and `--no-track` options.
......@@ -55,7 +55,7 @@ has a reflog then the reflog will also be deleted.
Use -r together with -d to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
in the remote repository or if 'git-fetch' was configured not to fetch
in the remote repository or if 'git fetch' was configured not to fetch
them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a
way to clean up all obsolete remote-tracking branches.
......@@ -76,7 +76,7 @@ OPTIONS
-f::
--force::
Reset <branchname> to <startpoint> if <branchname> exists
already. Without `-f` 'git-branch' refuses to change an existing branch.
already. Without `-f` 'git branch' refuses to change an existing branch.
-m::
Move/rename a branch and the corresponding reflog.
......
......@@ -21,9 +21,9 @@ Some workflows require that one or more branches of development on one
machine be replicated on another machine, but the two machines cannot
be directly connected, and therefore the interactive git protocols (git,
ssh, rsync, http) cannot be used. This command provides support for
'git-fetch' and 'git-pull' to operate by packaging objects and references
'git fetch' and 'git pull' to operate by packaging objects and references
in an archive at the originating machine, then importing those into
another repository using 'git-fetch' and 'git-pull'
another repository using 'git fetch' and 'git pull'
after moving the archive by some means (e.g., by sneakernet). As no
direct connection between the repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the
......@@ -35,14 +35,14 @@ OPTIONS
create <file>::
Used to create a bundle named 'file'. This requires the
'git-rev-list' arguments to define the bundle contents.
'git rev-list' arguments to define the bundle contents.
verify <file>::
Used to check that a bundle file is valid and will apply
cleanly to the current repository. This includes checks on the
bundle format itself as well as checking that the prerequisite
commits exist and are fully linked in the current repository.
'git-bundle' prints a list of missing commits, if any, and exits
'git bundle' prints a list of missing commits, if any, and exits
with a non-zero status.
list-heads <file>::
......@@ -51,15 +51,15 @@ list-heads <file>::
printed out.
unbundle <file>::
Passes the objects in the bundle to 'git-index-pack'
Passes the objects in the bundle to 'git index-pack'
for storage in the repository, then prints the names of all
defined references. If a list of references is given, only
references matching those in the list are printed. This command is
really plumbing, intended to be called only by 'git-fetch'.
really plumbing, intended to be called only by 'git fetch'.
[git-rev-list-args...]::
A list of arguments, acceptable to 'git-rev-parse' and
'git-rev-list', that specifies the specific objects and references
A list of arguments, acceptable to 'git rev-parse' and
'git rev-list', that specifies the specific objects and references
to transport. For example, `master\~10..master` causes the
current master reference to be packaged along with all objects
added since its 10th ancestor commit. There is no explicit
......@@ -69,16 +69,16 @@ unbundle <file>::
[refname...]::
A list of references used to limit the references reported as
available. This is principally of use to 'git-fetch', which
available. This is principally of use to 'git fetch', which
expects to receive only those references asked for and not
necessarily everything in the pack (in this case, 'git-bundle' acts
like 'git-fetch-pack').
necessarily everything in the pack (in this case, 'git bundle' acts
like 'git fetch-pack').
SPECIFYING REFERENCES
---------------------
'git-bundle' will only package references that are shown by
'git-show-ref': this includes heads, tags, and remote heads. References
'git bundle' will only package references that are shown by
'git show-ref': this includes heads, tags, and remote heads. References
such as `master\~1` cannot be packaged, but are perfectly suitable for
defining the basis. More than one reference may be packaged, and more
than one basis can be specified. The objects packaged are those not
......
......@@ -60,7 +60,7 @@ reference name expressions (see linkgit:git-rev-parse[1]):
. A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
value and store it in dstref" in fetch and push operations.
It may also be used to select a specific object such as with
'git-cat-file': "git cat-file blob v1.3.3:refs.c".
'git cat-file': "git cat-file blob v1.3.3:refs.c".
. at-open-brace `@{` is used as a notation to access a reflog entry.
......
......@@ -88,7 +88,7 @@ $ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
which will force all existing `*.h` files to be replaced with their
cached copies. If an empty command line implied "all", then this would
force-refresh everything in the index, which was not the point. But
since 'git-checkout-index' accepts --stdin it would be faster to use:
since 'git checkout-index' accepts --stdin it would be faster to use:
----------------
$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
......@@ -102,7 +102,7 @@ Using `--` is probably a good policy in scripts.
Using --temp or --stage=all
---------------------------
When `--temp` is used (or implied by `--stage=all`)
'git-checkout-index' will create a temporary file for each index
'git checkout-index' will create a temporary file for each index
entry being checked out. The index will not be updated with stat
information. These options can be useful if the caller needs all
stages of all unmerged entries so that the unmerged files can be
......@@ -147,9 +147,9 @@ To update and refresh only the files already checked out::
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
----------------
Using 'git-checkout-index' to "export an entire tree"::
Using 'git checkout-index' to "export an entire tree"::
The prefix ability basically makes it trivial to use
'git-checkout-index' as an "export as tree" function.
'git checkout-index' as an "export as tree" function.
Just read the desired tree into the index, and do:
+
----------------
......
......@@ -24,7 +24,7 @@ OPTIONS
-e::
--edit::
With this option, 'git-cherry-pick' will let you edit the commit
With this option, 'git cherry-pick' will let you edit the commit
message prior to committing.
-x::
......
......@@ -14,7 +14,7 @@ DESCRIPTION
The changeset (or "diff") of each commit between the fork-point and <head>
is compared against each commit between the fork-point and <upstream>.
The commits are compared with their 'patch id', obtained from
the 'git-patch-id' program.
the 'git patch-id' program.
Every commit that doesn't exist in the <upstream> branch
has its id (sha1) reported, prefixed by a symbol. The ones that have
......@@ -37,8 +37,8 @@ to and including <limit> are not reported:
\__*__*__<limit>__-__+__> <head>
Because 'git-cherry' compares the changeset rather than the commit id
(sha1), you can use 'git-cherry' to find out if a commit you made locally
Because 'git cherry' compares the changeset rather than the commit id
(sha1), you can use 'git cherry' to find out if a commit you made locally
has been applied <upstream> under a different commit id. For example,
this will happen if you're feeding patches <upstream> via email rather
than pushing or pulling commits directly.
......
......@@ -14,9 +14,9 @@ DESCRIPTION
A Tcl/Tk based graphical interface to review modified files, stage
them into the index, enter a commit message and record the new
commit onto the current branch. This interface is an alternative
to the less interactive 'git-commit' program.
to the less interactive 'git commit' program.
'git-citool' is actually a standard alias for `git gui citool`.
'git citool' is actually a standard alias for `git gui citool`.
See linkgit:git-gui[1] for more details.
Author
......
......@@ -34,7 +34,7 @@ OPTIONS
-f::
--force::
If the git configuration specifies clean.requireForce as true,
'git-clean' will refuse to run unless given -f or -n.
'git clean' will refuse to run unless given -f or -n.
-n::
--dry-run::
......@@ -48,7 +48,7 @@ OPTIONS
-x::
Don't use the ignore rules. This allows removing all untracked
files, including build products. This can be used (possibly in
conjunction with 'git-reset') to create a pristine
conjunction with 'git reset') to create a pristine
working directory to test a clean build.
-X::
......
......@@ -70,7 +70,7 @@ is taken from the configuration items user.name and user.email, or, if not
present, system user name and fully qualified hostname.
A commit comment is read from stdin. If a changelog
entry is not provided via "<" redirection, 'git-commit-tree' will just wait
entry is not provided via "<" redirection, 'git commit-tree' will just wait
for one to be entered and terminated with ^D.
include::date-formats.txt[]
......
......@@ -20,11 +20,11 @@ with a log message from the user describing the changes.
The content to be added can be specified in several ways:
1. by using 'git-add' to incrementally "add" changes to the
1. by using 'git add' to incrementally "add" changes to the
index before using the 'commit' command (Note: even modified
files must be "added");
2. by using 'git-rm' to remove files from the working tree
2. by using 'git rm' to remove files from the working tree
and the index, again before using the 'commit' command;
3. by listing files as arguments to the 'commit' command, in which
......@@ -40,14 +40,14 @@ The content to be added can be specified in several ways:
5. by using the --interactive switch with the 'commit' command to decide one
by one which files should be part of the commit, before finalizing the
operation. Currently, this is done by invoking 'git-add --interactive'.
operation. Currently, this is done by invoking 'git add --interactive'.
The `--dry-run` option can be used to obtain a
summary of what is included by any of the above for the next
commit by giving the same set of parameters (options and paths).
If you make a commit and then find a mistake immediately after
that, you can recover from it with 'git-reset'.
that, you can recover from it with 'git reset'.
OPTIONS
......@@ -184,7 +184,7 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
Make a commit only from the paths specified on the
command line, disregarding any contents that have been
staged so far. This is the default mode of operation of
'git-commit' if any paths are given on the command line,
'git commit' if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with '--amend', then
no paths need to be specified, which can be used to amend
......@@ -241,10 +241,10 @@ EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
called the "index" with 'git-add'. A file can be
called the "index" with 'git add'. A file can be
reverted back, only in the index but not in the working tree,
to that of the last commit with `git reset HEAD -- <file>`,
which effectively reverts 'git-add' and prevents the changes to
which effectively reverts 'git add' and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
`git commit` (without any pathname parameter) is used to record what
......@@ -300,13 +300,13 @@ $ git commit
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
After a merge (initiated by 'git-merge' or 'git-pull') stops
After a merge (initiated by 'git merge' or 'git pull') stops
because of conflicts, cleanly merged
paths are already staged to be committed for you, and paths that
conflicted are left in unmerged state. You would have to first
check which paths are conflicting with 'git-status'
check which paths are conflicting with 'git status'
and after fixing them manually in your working tree, you would
stage the result as usual with 'git-add':
stage the result as usual with 'git add':
------------
$ git status | grep unmerged
......
......@@ -38,7 +38,7 @@ you want to handle the lines that do *not* match the regex, just
prepend a single exclamation mark in front (see also <<EXAMPLES>>).
The type specifier can be either '--int' or '--bool', which will make
'git-config' ensure that the variable(s) are of the given type and
'git config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
a "true" or "false" string for bool). If no type specifier is passed,
no checks or transformations are performed on the value.
......@@ -124,16 +124,16 @@ See also <<FILES>>.
List all variables set in config file.
--bool::
'git-config' will ensure that the output is "true" or "false"
'git config' will ensure that the output is "true" or "false"
--int::
'git-config' will ensure that the output is a simple
'git config' will ensure that the output is a simple
decimal number. An optional value suffix of 'k', 'm', or 'g'
in the config file will cause the value to be multiplied
by 1024, 1048576, or 1073741824 prior to output.
--bool-or-int::
'git-config' will ensure that the output matches the format of
'git config' will ensure that the output matches the format of
either --bool or --int, as described above.
-z::
......@@ -173,7 +173,7 @@ FILES
-----