git/Documentation/git-commit.txt

144 lines
4.3 KiB
Plaintext
Raw Normal View History

git-commit(1)
=============
NAME
----
git-commit - Record your changes
SYNOPSIS
--------
[verse]
'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
[-e] [--author <author>] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
Updates the index file for given paths, or all modified files if
'-a' is specified, and makes a commit object. The command
VISUAL and EDITOR environment variables to edit the commit log
message.
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
information.
OPTIONS
-------
-a|--all::
Update all paths in the index file. This flag notices
files that have been modified and deleted, but new files
you have not told git about are not affected.
-c or -C <commit>::
Take existing commit object, and reuse the log message
and the authorship information (including the timestamp)
when creating the commit. With '-C', the editor is not
invoked; with '-c' the user can further edit the commit
message.
-F <file>::
Take the commit message from the given file. Use '-' to
read the message from the standard input.
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 16:07:44 +08:00
--author <author>::
Override the author name used in the commit. Use
`A U Thor <author@example.com>` format.
-m <msg>::
Use the given <msg> as the commit message.
-s|--signoff::
Add Signed-off-by line at the end of the commit message.
-v|--verify::
Look for suspicious lines the commit introduces, and
abort committing if there is one. The definition of
'suspicious lines' is currently the lines that has
trailing whitespaces, and the lines whose indentation
has a SP character immediately followed by a TAB
character. This is the default.
-n|--no-verify::
The opposite of `--verify`.
-e|--edit::
The message taken from file with `-F`, command line with
`-m`, and from file with `-C` are usually used as the
commit log message unmodified. This option lets you
further edit the message taken from these sources.
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 16:07:44 +08:00
-i|--include::
Instead of committing only the files specified on the
command line, update them in the index file and then
commit the whole index. This is the traditional
behaviour.
-o|--only::
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 16:07:44 +08:00
Commit only the files specified on the command line.
This format cannot be used during a merge, nor when the
index and the latest commit does not match on the
specified paths to avoid confusion.
--::
Do not interpret any more arguments as options.
<file>...::
Files to be committed. The meaning of these is
different between `--include` and `--only`. Without
either, it defaults `--only` semantics.
If you make a commit and then found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
git-commit: revamp the git-commit semantics. - "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-05 16:07:44 +08:00
Discussion
----------
`git commit` without _any_ parameter commits the tree structure
recorded by the current index file. This is a whole-tree commit
even the command is invoked from a subdirectory.
`git commit --include paths...` is equivalent to
git update-index --remove paths...
git commit
That is, update the specified paths to the index and then commit
the whole tree.
`git commit paths...` largely bypasses the index file and
commits only the changes made to the specified paths. It has
however several safety valves to prevent confusion.
. It refuses to run during a merge (i.e. when
`$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
that the traditional semantics now needs -i flag.
. It refuses to run if named `paths...` are different in HEAD
and the index (ditto about reminding). Added paths are OK.
This is because an earlier `git diff` (not `git diff HEAD`)
would have shown the differences since the last `git
update-index paths...` to the user, and an inexperienced user
may mistakenly think that the changes between the index and
the HEAD (i.e. earlier changes made before the last `git
update-index paths...` was done) are not being committed.
. It reads HEAD commit into a temporary index file, updates the
specified `paths...` and makes a commit. At the same time,
the real index file is also updated with the same `paths...`.
`git commit --all` updates the index file with _all_ changes to
the working tree, and makes a whole-tree commit, regardless of
which subdirectory the command is invoked in.
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
Junio C Hamano <junkio@cox.net>
GIT
---
Part of the gitlink:git[7] suite