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
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 `git-status` command can be used to obtain a
+The 'git-status' command 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 you would give to
this command.
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
read the message from the standard input.
--author=<author>::
- Override the author name used in the commit. Use
- `A U Thor <author@example.com>` format.
+ Override the author name used in the commit. You can use the
+ standard `A U Thor <author@example.com>` format. Otherwise,
+ an existing commit that matches the given string and its author
+ name is used.
-m <msg>::
--message=<msg>::
-s::
--signoff::
- Add Signed-off-by line at the end of the commit message.
+ Add Signed-off-by line by the commiter at the end of the commit
+ log message.
-n::
--no-verify::
------
but can be used to amend a merge commit.
--
++
+You should understand the implications of rewriting history if you
+amend a commit that has already been published. (See the "RECOVERING
+FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
-i::
--include::
--------
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
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
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
-Junio C Hamano <junkio@cox.net>
+Junio C Hamano <gitster@pobox.com>
GIT