summaryrefslogtreecommitdiff
path: root/Documentation/git-commit.txt
diff options
context:
space:
mode:
authorLibravatar Thomas Rast <trast@student.ethz.ch>2010-01-10 00:33:00 +0100
committerLibravatar Thomas Rast <trast@student.ethz.ch>2010-01-10 13:01:28 +0100
commit0b444cdb19bcfcc7f59b7b00783cbfbbc5ddcf63 (patch)
treefbc79ccb4f6e809a560bd807c4a17dd6e6681161 /Documentation/git-commit.txt
parentDocumentation: format full commands in typewriter font (diff)
downloadtgif-0b444cdb19bcfcc7f59b7b00783cbfbbc5ddcf63.tar.xz
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 647ac70 (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.
Diffstat (limited to 'Documentation/git-commit.txt')
-rw-r--r--Documentation/git-commit.txt20
1 files changed, 10 insertions, 10 deletions
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 5fb43f9320..c322c759fd 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.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