undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation/git-commit: rewrite to make it more end-user friendly.

Browse Source 
Signed-off-by: Junio C Hamano <junkio@cox.net>
This commit is contained in:
Junio C Hamano 2006-12-08 21:48:07 -08:00
parent 366bfcb68f
commit 6c96753df9
1 changed files with 149 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

217
Documentation/git-commit.txt
View File

@ -14,25 +14,41 @@ SYNOPSIS
DESCRIPTION DESCRIPTION
----------- -----------
Updates the index file for given paths, or all modified files if Use 'git commit' when you want to record your changes into the repository
'-a' is specified, and makes a commit object. The command specified along with a log message describing what the commit is about. All changes
by either the VISUAL or EDITOR environment variables are used to edit to be committed must be explicitly identified using one of the following
the commit log message. methods:
Several environment variable are used during commits. They are 1. by using gitlink:git-add[1] to incrementally "add" changes to the
documented in gitlink:git-commit-tree[1]. next commit before using the 'commit' command (Note: even modified
files must be "added");
2. by using gitlink:git-rm[1] to identify content removal for the next
commit, again before using the 'commit' command;
3. by directly listing files containing changes to be committed as arguments
to the 'commit' command, in which cases only those files alone will be
considered for the commit;
4. by using the -a switch with the 'commit' command to automatically "add"
changes from all known files i.e. files that have already been committed
before, and perform the actual commit.
The gitlink:git-status[1] 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 found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
information.
OPTIONS OPTIONS
------- -------
-a|--all:: -a|--all::
Update all paths in the index file. This flag notices Tell the command to automatically stage files that have
files that have been modified and deleted, but new files been modified and deleted, but new files you have not
you have not told git about are not affected. told git about are not affected.
-c or -C <commit>:: -c or -C <commit>::
Take existing commit object, and reuse the log message Take existing commit object, and reuse the log message
@ -55,16 +71,13 @@ OPTIONS
-s|--signoff:: -s|--signoff::
Add Signed-off-by line at the end of the commit message. Add Signed-off-by line at the end of the commit message.
-v|--verify:: --no-verify::
Look for suspicious lines the commit introduces, and By default, the command looks for suspicious lines the
abort committing if there is one. The definition of commit introduces, and aborts committing if there is one.
'suspicious lines' is currently the lines that has The definition of 'suspicious lines' is currently the
trailing whitespaces, and the lines whose indentation lines that has trailing whitespaces, and the lines whose
has a SP character immediately followed by a TAB indentation has a SP character immediately followed by a
character. This is the default. TAB character. This option turns off the check.
-n|--no-verify::
The opposite of `--verify`.
-e|--edit:: -e|--edit::
The message taken from file with `-F`, command line with The message taken from file with `-F`, command line with
@ -95,69 +108,137 @@ but can be used to amend a merge commit.
-- --
-i|--include:: -i|--include::
Instead of committing only the files specified on the Before making a commit out of staged contents so far,
command line, update them in the index file and then stage the contents of paths given on the command line
commit the whole index. This is the traditional as well. This is usually not what you want unless you
behavior. are concluding a conflicted merge.
-o|--only::
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. Do not interpret any more arguments as options.
<file>...:: <file>...::
Files to be committed. The meaning of these is When files are given on the command line, the command
different between `--include` and `--only`. Without commits the contents of the named files, without
either, it defaults `--only` semantics. recording the changes already staged. The contents of
these files are also staged for the next commit on top
If you make a commit and then found a mistake immediately after of what have been staged before.
that, you can recover from it with gitlink:git-reset[1].
Discussion 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 gitlink:git-add[1]. Removal
of a file is staged with gitlink:git-rm[1]. After building the
state to be committed incrementally with these commands, `git
commit` (without any pathname parameter) is used to record what
has been staged so far. This is the most basic form of the
command. An example:
`git commit` without _any_ parameter commits the tree structure ------------
recorded by the current index file. This is a whole-tree commit $ edit hello.c
even the command is invoked from a subdirectory. $ git rm goodbye.c
$ git add hello.c
$ git commit
------------
`git commit --include paths...` is equivalent to ////////////
We should fix 'git rm' to remove goodbye.c from both index and
working tree for the above example.
////////////
git update-index --remove paths... Instead of staging files after each individual change, you can
git commit tell `git commit` to notice the changes to the files whose
contents are tracked in
your working tree and do corresponding `git add` and `git rm`
for you. That is, this example does the same as the earlier
example if there is no other change in your working tree:
That is, update the specified paths to the index and then commit ------------
the whole tree. $ edit hello.c
$ rm goodbye.c
$ git commit -a
------------
`git commit paths...` largely bypasses the index file and The command `git commit -a` first looks at your working tree,
commits only the changes made to the specified paths. It has notices that you have modified hello.c and removed goodbye.c,
however several safety valves to prevent confusion. and performs necessary `git add` and `git rm` for you.
. It refuses to run during a merge (i.e. when After staging changes to many files, you can alter the order the
`$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users changes are recorded in, by giving pathnames to `git commit`.
that the traditional semantics now needs -i flag. When pathnames are given, the command makes a commit that
only records the changes made to the named paths:
. It refuses to run if named `paths...` are different in HEAD ------------
and the index (ditto about reminding). Added paths are OK. $ edit hello.c hello.h
This is because an earlier `git diff` (not `git diff HEAD`) $ git add hello.c hello.h
would have shown the differences since the last `git $ edit Makefile
update-index paths...` to the user, and an inexperienced user $ git commit Makefile
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 This makes a commit that records the modification to `Makefile`.
specified `paths...` and makes a commit. At the same time, The changes staged for `hello.c` and `hello.h` are not included
the real index file is also updated with the same `paths...`. in the resulting commit. However, their changes are not lost --
they are still staged and merely held back. After the above
sequence, if you do:
`git commit --all` updates the index file with _all_ changes to ------------
the working tree, and makes a whole-tree commit, regardless of $ git commit
which subdirectory the command is invoked in. ------------
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
After a merge (initiated by either gitlink:git-merge[1] or
gitlink:git-pull[1]) 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 gitlink:git-status[1]
and after fixing them manually in your working tree, you would
stage the result as usual with gitlink:git-add[1]:
------------
$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c
------------
After resolving conflicts and staging the result, `git ls-files -u`
would stop mentioning the conflicted path. When you are done,
run `git commit` to finally record the merge:
------------
$ git commit
------------
As with the case to record your own changes, you can use `-a`
option to save typing. One difference is that during a merge
resolution, you cannot use `git commit` with pathnames to
alter the order the changes are committed, because the merge
should be recorded as a single commit. In fact, the command
refuses to run when given pathnames (but see `-i` option).
ENVIRONMENT VARIABLES
---------------------
The command specified by either the VISUAL or EDITOR environment
variables is used to edit the commit log message.
HOOKS
-----
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
information.
SEE ALSO
--------
gitlink:git-add[1],
gitlink:git-rm[1],
gitlink:git-mv[1],
gitlink:git-merge[1],
gitlink:git-commit-tree[1]
Author Author
------ ------