this option, `git pull` defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.
-color.pager::
- A boolean to enable/disable colored output when the pager is in
- use (default is true).
-
color.diff::
When true (or `always`), always use colors in patch.
When false (or `never`), never. When set to `auto`, use
`red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, or
`white`.
+color.pager::
+ A boolean to enable/disable colored output when the pager is in
+ use (default is true).
+
+color.status::
+ A boolean to enable/disable color in the output of
+ gitlink:git-status[1]. May be set to `true` (or `always`),
+ `false` (or `never`) or `auto`, in which case colors are used
+ only when the output is to a terminal. Defaults to false.
+
+color.status.<slot>::
+ Use customized color for status colorization. `<slot>` is
+ one of `header` (the header text of the status message),
+ `updated` (files which are updated but not committed),
+ `changed` (files which are changed but not updated in the index),
+ or `untracked` (files which are not tracked by git). The values of
+ these variables may be specified as in color.diff.<slot>.
+
diff.renameLimit::
The number of files to consider when performing the copy/rename
detection; equivalent to the git diff option '-l'.
The default set of branches for gitlink:git-show-branch[1].
See gitlink:git-show-branch[1].
-color.status::
- A boolean to enable/disable color in the output of
- gitlink:git-status[1]. May be set to `true` (or `always`),
- `false` (or `never`) or `auto`, in which case colors are used
- only when the output is to a terminal. Defaults to false.
-
-color.status.<slot>::
- Use customized color for status colorization. `<slot>` is
- one of `header` (the header text of the status message),
- `updated` (files which are updated but not committed),
- `changed` (files which are changed but not updated in the index),
- or `untracked` (files which are not tracked by git). The values of
- these variables may be specified as in color.diff.<slot>.
-
tar.umask::
By default, gitlink:git-tar-tree[1] sets file and directories modes
to 0666 or 0777. While this is both useful and acceptable for projects
<h2>NAME</h2>\r
<div class="sectionbody">\r
<p>git-add -\r
- Add files to the index file\r
+ Add file contents to the changeset to be committed next\r
</p>\r
</div>\r
</div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
-<p>A simple wrapper for git-update-index to add files to the index,\r
-for people used to do "cvs add".</p>\r
-<p>It only adds non-ignored files, to add ignored files use\r
+<p>All the changed file contents to be committed together in a single set\r
+of changes must be "added" with the <em>add</em> command before using the\r
+<em>commit</em> command. This is not only for adding new files. Even modified\r
+files must be added to the set of changes about to be committed.</p>\r
+<p>This command can be performed multiple times before a commit. The added\r
+content corresponds to the state of specified file(s) at the time the\r
+<em>add</em> command is used. This means the <em>commit</em> command will not consider\r
+subsequent changes to already added content if it is not added again before\r
+the commit.</p>\r
+<p>The <em>git status</em> command can be used to obtain a summary of what is included\r
+for the next commit.</p>\r
+<p>This command only adds non-ignored files, to add ignored files use\r
"git update-index --add".</p>\r
+<p>Please see <a href="git-commit.html">git-commit(1)</a> for alternative ways to add content to a\r
+commit.</p>\r
</div>\r
<h2>OPTIONS</h2>\r
<div class="sectionbody">\r
</dt>\r
<dd>\r
<p>\r
- Files to add to the index (see <a href="git-ls-files.html">git-ls-files(1)</a>).\r
+ Files to add content from.\r
</p>\r
</dd>\r
<dt>\r
</dd>\r
</dl>\r
</div>\r
-<h2>DISCUSSION</h2>\r
-<div class="sectionbody">\r
-<p>The list of <file> given to the command is fed to <tt>git-ls-files</tt>\r
-command to list files that are not registered in the index and\r
-are not ignored/excluded by <tt>$GIT_DIR/info/exclude</tt> file or\r
-<tt>.gitignore</tt> file in each directory. This means two things:</p>\r
-<ol>\r
-<li>\r
-<p>\r
-You can put the name of a directory on the command line, and\r
- the command will add all files in it and its subdirectories;\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-Giving the name of a file that is already in index does not\r
- run <tt>git-update-index</tt> on that path.\r
-</p>\r
-</li>\r
-</ol>\r
-</div>\r
<h2>EXAMPLES</h2>\r
<div class="sectionbody">\r
<dl>\r
</dt>\r
<dd>\r
<p>\r
- Adds all <tt>*.txt</tt> files that are not in the index under\r
- <tt>Documentation</tt> directory and its subdirectories.\r
+ Adds content from all <tt>*.txt</tt> files under <tt>Documentation</tt>\r
+ directory and its subdirectories.\r
</p>\r
<p>Note that the asterisk <tt>*</tt> is quoted from the shell in this\r
example; this lets the command to include the files from\r
</dt>\r
<dd>\r
<p>\r
- Adds all git-*.sh scripts that are not in the index.\r
+ Considers adding content from all git-*.sh scripts.\r
Because this example lets shell expand the asterisk\r
(i.e. you are listing the files explicitly), it does not\r
- add <tt>subdir/git-foo.sh</tt> to the index.\r
+ consider <tt>subdir/git-foo.sh</tt>.\r
</p>\r
</dd>\r
</dl>\r
</div>\r
<h2>See Also</h2>\r
<div class="sectionbody">\r
-<p><a href="git-rm.html">git-rm(1)</a>\r
-<a href="git-ls-files.html">git-ls-files(1)</a></p>\r
+<p><a href="git-status.html">git-status(1)</a>\r
+<a href="git-rm.html">git-rm(1)</a>\r
+<a href="git-mv.html">git-mv(1)</a>\r
+<a href="git-commit.html">git-commit(1)</a>\r
+<a href="git-update-index.html">git-update-index(1)</a></p>\r
</div>\r
<h2>Author</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:40:49 UTC\r
+Last updated 13-Dec-2006 21:32:04 UTC\r
</div>\r
</div>\r
</body>\r
NAME
----
-git-add - Add files to the index file
+git-add - Add file contents to the changeset to be committed next
SYNOPSIS
--------
DESCRIPTION
-----------
-A simple wrapper for git-update-index to add files to the index,
-for people used to do "cvs add".
+All the changed file contents to be committed together in a single set
+of changes must be "added" with the 'add' command before using the
+'commit' command. This is not only for adding new files. Even modified
+files must be added to the set of changes about to be committed.
-It only adds non-ignored files, to add ignored files use
+This command can be performed multiple times before a commit. The added
+content corresponds to the state of specified file(s) at the time the
+'add' command is used. This means the 'commit' command will not consider
+subsequent changes to already added content if it is not added again before
+the commit.
+
+The 'git status' command can be used to obtain a summary of what is included
+for the next commit.
+
+This command only adds non-ignored files, to add ignored files use
"git update-index --add".
+Please see gitlink:git-commit[1] for alternative ways to add content to a
+commit.
+
+
OPTIONS
-------
<file>...::
- Files to add to the index (see gitlink:git-ls-files[1]).
+ Files to add content from.
-n::
Don't actually add the file(s), just show if they exist.
for command-line options).
-DISCUSSION
-----------
-
-The list of <file> given to the command is fed to `git-ls-files`
-command to list files that are not registered in the index and
-are not ignored/excluded by `$GIT_DIR/info/exclude` file or
-`.gitignore` file in each directory. This means two things:
-
-. You can put the name of a directory on the command line, and
- the command will add all files in it and its subdirectories;
-
-. Giving the name of a file that is already in index does not
- run `git-update-index` on that path.
-
-
EXAMPLES
--------
git-add Documentation/\\*.txt::
- Adds all `\*.txt` files that are not in the index under
- `Documentation` directory and its subdirectories.
+ Adds content from all `\*.txt` files under `Documentation`
+ directory and its subdirectories.
+
Note that the asterisk `\*` is quoted from the shell in this
example; this lets the command to include the files from
git-add git-*.sh::
- Adds all git-*.sh scripts that are not in the index.
+ Considers adding content from all git-*.sh scripts.
Because this example lets shell expand the asterisk
(i.e. you are listing the files explicitly), it does not
- add `subdir/git-foo.sh` to the index.
+ consider `subdir/git-foo.sh`.
See Also
--------
+gitlink:git-status[1]
gitlink:git-rm[1]
-gitlink:git-ls-files[1]
+gitlink:git-mv[1]
+gitlink:git-commit[1]
+gitlink:git-update-index[1]
Author
------
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
<div class="verseblock">\r
-<div class="content"><em>git-branch</em> [-r] [-a] [-v] [--abbrev=<length>]\r
+<div class="content"><em>git-branch</em> [-r | -a] [-v [--abbrev=<length>]]\r
<em>git-branch</em> [-l] [-f] <branchname> [<start-point>]\r
+<em>git-branch</em> (-m | -M) [<oldbranch>] <newbranch>\r
<em>git-branch</em> (-d | -D) <branchname>…</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
It will start out with a head equal to the one given as <start-point>.\r
If no <start-point> is given, the branch will be created with a head\r
equal to that of the currently checked out branch.</p>\r
+<p>With a <em>-m</em> or <em>-M</em> option, <oldbranch> will be renamed to <newbranch>.\r
+If <oldbranch> had a corresponding reflog, it is renamed to match\r
+<newbranch>, and a reflog entry is created to remember the branch\r
+renaming. If <newbranch> exists, -M must be used to force the rename\r
+to happen.</p>\r
<p>With a <tt>-d</tt> or <tt>-D</tt> option, <tt><branchname></tt> will be deleted. You may\r
specify more than one branch for deletion. If the branch currently\r
has a ref log then the ref log will also be deleted.</p>\r
</p>\r
</dd>\r
<dt>\r
+-m\r
+</dt>\r
+<dd>\r
+<p>\r
+ Move/rename a branch and the corresponding reflog.\r
+</p>\r
+</dd>\r
+<dt>\r
+-M\r
+</dt>\r
+<dd>\r
+<p>\r
+ Move/rename a branch even if the new branchname already exists.\r
+</p>\r
+</dd>\r
+<dt>\r
-r\r
</dt>\r
<dd>\r
</dt>\r
<dd>\r
<p>\r
- Show sha1 and subject message for each head.\r
+ Show sha1 and commit subjectline for each head.\r
</p>\r
</dd>\r
<dt>\r
is omitted, the current branch is assumed.\r
</p>\r
</dd>\r
+<dt>\r
+<oldbranch>\r
+</dt>\r
+<dd>\r
+<p>\r
+ The name of an existing branch to rename.\r
+</p>\r
+</dd>\r
+<dt>\r
+<newbranch>\r
+</dt>\r
+<dd>\r
+<p>\r
+ The new name for an existing branch. The same restrictions as for\r
+ <branchname> applies.\r
+</p>\r
+</dd>\r
</dl>\r
</div>\r
<h2>Examples</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 25-Nov-2006 10:05:14 UTC\r
+Last updated 13-Dec-2006 21:32:04 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
[verse]
-'git-branch' [-r] [-a] [-v] [--abbrev=<length>]
+'git-branch' [-r | -a] [-v [--abbrev=<length>]]
'git-branch' [-l] [-f] <branchname> [<start-point>]
+'git-branch' (-m | -M) [<oldbranch>] <newbranch>
'git-branch' (-d | -D) <branchname>...
DESCRIPTION
If no <start-point> is given, the branch will be created with a head
equal to that of the currently checked out branch.
+With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
+If <oldbranch> had a corresponding reflog, it is renamed to match
+<newbranch>, and a reflog entry is created to remember the branch
+renaming. If <newbranch> exists, -M must be used to force the rename
+to happen.
+
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a ref log then the ref log will also be deleted.
Force the creation of a new branch even if it means deleting
a branch that already exists with the same name.
+-m::
+ Move/rename a branch and the corresponding reflog.
+
+-M::
+ Move/rename a branch even if the new branchname already exists.
+
-r::
List the remote-tracking branches.
List both remote-tracking branches and local branches.
-v::
- Show sha1 and subject message for each head.
+ Show sha1 and commit subjectline for each head.
--abbrev=<length>::
Alter minimum display length for sha1 in output listing,
be given as a branch name, a commit-id, or a tag. If this option
is omitted, the current branch is assumed.
+<oldbranch>::
+ The name of an existing branch to rename.
+
+<newbranch>::
+ The new name for an existing branch. The same restrictions as for
+ <branchname> applies.
Examples
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
-<p>Updates the index file for given paths, or all modified files if\r
-<em>-a</em> is specified, and makes a commit object. The command specified\r
-by either the VISUAL or EDITOR environment variables are used to edit\r
-the commit log message.</p>\r
-<p>Several environment variable are used during commits. They are\r
-documented in <a href="git-commit-tree.html">git-commit-tree(1)</a>.</p>\r
-<p>This command can run <tt>commit-msg</tt>, <tt>pre-commit</tt>, and\r
-<tt>post-commit</tt> hooks. See <a href="hooks.html">hooks</a> for more\r
-information.</p>\r
+<p>Use <em>git commit</em> when you want to record your changes into the repository\r
+along with a log message describing what the commit is about. All changes\r
+to be committed must be explicitly identified using one of the following\r
+methods:</p>\r
+<ol>\r
+<li>\r
+<p>\r
+by using <a href="git-add.html">git-add(1)</a> to incrementally "add" changes to the\r
+ next commit before using the <em>commit</em> command (Note: even modified\r
+ files must be "added");\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+by using <a href="git-rm.html">git-rm(1)</a> to identify content removal for the next\r
+ commit, again before using the <em>commit</em> command;\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+by directly listing files containing changes to be committed as arguments\r
+ to the <em>commit</em> command, in which cases only those files alone will be\r
+ considered for the commit;\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+by using the -a switch with the <em>commit</em> command to automatically "add"\r
+ changes from all known files i.e. files that have already been committed\r
+ before, and perform the actual commit.\r
+</p>\r
+</li>\r
+</ol>\r
+<p>The <a href="git-status.html">git-status(1)</a> command can be used to obtain a\r
+summary of what is included by any of the above for the next\r
+commit by giving the same set of parameters you would give to\r
+this command.</p>\r
+<p>If you make a commit and then found a mistake immediately after\r
+that, you can recover from it with <a href="git-reset.html">git-reset(1)</a>.</p>\r
</div>\r
<h2>OPTIONS</h2>\r
<div class="sectionbody">\r
</dt>\r
<dd>\r
<p>\r
- Update all paths in the index file. This flag notices\r
- files that have been modified and deleted, but new files\r
- you have not told git about are not affected.\r
+ Tell the command to automatically stage files that have\r
+ been modified and deleted, but new files you have not\r
+ told git about are not affected.\r
</p>\r
</dd>\r
<dt>\r
</p>\r
</dd>\r
<dt>\r
--v|--verify\r
-</dt>\r
-<dd>\r
-<p>\r
- Look for suspicious lines the commit introduces, and\r
- abort committing if there is one. The definition of\r
- <em>suspicious lines</em> is currently the lines that has\r
- trailing whitespaces, and the lines whose indentation\r
- has a SP character immediately followed by a TAB\r
- character. This is the default.\r
-</p>\r
-</dd>\r
-<dt>\r
--n|--no-verify\r
+--no-verify\r
</dt>\r
<dd>\r
<p>\r
- The opposite of <tt>--verify</tt>.\r
+ By default, the command looks for suspicious lines the\r
+ commit introduces, and aborts committing if there is one.\r
+ The definition of <em>suspicious lines</em> is currently the\r
+ lines that has trailing whitespaces, and the lines whose\r
+ indentation has a SP character immediately followed by a\r
+ TAB character. This option turns off the check.\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- Instead of committing only the files specified on the\r
- command line, update them in the index file and then\r
- commit the whole index. This is the traditional\r
- behavior.\r
-</p>\r
-</dd>\r
-<dt>\r
--o|--only\r
-</dt>\r
-<dd>\r
-<p>\r
- Commit only the files specified on the command line.\r
- This format cannot be used during a merge, nor when the\r
- index and the latest commit does not match on the\r
- specified paths to avoid confusion.\r
+ Before making a commit out of staged contents so far,\r
+ stage the contents of paths given on the command line\r
+ as well. This is usually not what you want unless you\r
+ are concluding a conflicted merge.\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- Files to be committed. The meaning of these is\r
- different between <tt>--include</tt> and <tt>--only</tt>. Without\r
- either, it defaults <tt>--only</tt> semantics.\r
+ When files are given on the command line, the command\r
+ commits the contents of the named files, without\r
+ recording the changes already staged. The contents of\r
+ these files are also staged for the next commit on top\r
+ of what have been staged before.\r
</p>\r
</dd>\r
</dl>\r
-<p>If you make a commit and then found a mistake immediately after\r
-that, you can recover from it with <a href="git-reset.html">git-reset(1)</a>.</p>\r
</div>\r
-<h2>Discussion</h2>\r
+<h2>EXAMPLES</h2>\r
<div class="sectionbody">\r
-<p><tt>git commit</tt> without _any_ parameter commits the tree structure\r
-recorded by the current index file. This is a whole-tree commit\r
-even the command is invoked from a subdirectory.</p>\r
-<p><tt>git commit --include paths…</tt> is equivalent to</p>\r
-<div class="literalblock">\r
+<p>When recording your own work, the contents of modified files in\r
+your working tree are temporarily stored to a staging area\r
+called the "index" with <a href="git-add.html">git-add(1)</a>. Removal\r
+of a file is staged with <a href="git-rm.html">git-rm(1)</a>. After building the\r
+state to be committed incrementally with these commands, <tt>git\r
+commit</tt> (without any pathname parameter) is used to record what\r
+has been staged so far. This is the most basic form of the\r
+command. An example:</p>\r
+<div class="listingblock">\r
<div class="content">\r
-<pre><tt>git update-index --remove paths...\r
-git commit</tt></pre>\r
+<pre><tt>$ edit hello.c\r
+$ git rm goodbye.c\r
+$ git add hello.c\r
+$ git commit</tt></pre>\r
</div></div>\r
-<p>That is, update the specified paths to the index and then commit\r
-the whole tree.</p>\r
-<p><tt>git commit paths…</tt> largely bypasses the index file and\r
-commits only the changes made to the specified paths. It has\r
-however several safety valves to prevent confusion.</p>\r
-<ol>\r
-<li>\r
-<p>\r
-It refuses to run during a merge (i.e. when\r
- <tt>$GIT_DIR/MERGE_HEAD</tt> exists), and reminds trained git users\r
- that the traditional semantics now needs -i flag.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-It refuses to run if named <tt>paths…</tt> are different in HEAD\r
- and the index (ditto about reminding). Added paths are OK.\r
- This is because an earlier <tt>git diff</tt> (not <tt>git diff HEAD</tt>)\r
- would have shown the differences since the last <tt>git\r
- update-index paths…</tt> to the user, and an inexperienced user\r
- may mistakenly think that the changes between the index and\r
- the HEAD (i.e. earlier changes made before the last <tt>git\r
- update-index paths…</tt> was done) are not being committed.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-It reads HEAD commit into a temporary index file, updates the\r
- specified <tt>paths…</tt> and makes a commit. At the same time,\r
- the real index file is also updated with the same <tt>paths…</tt>.\r
-</p>\r
-</li>\r
-</ol>\r
-<p><tt>git commit --all</tt> updates the index file with _all_ changes to\r
-the working tree, and makes a whole-tree commit, regardless of\r
-which subdirectory the command is invoked in.</p>\r
+<p>Instead of staging files after each individual change, you can\r
+tell <tt>git commit</tt> to notice the changes to the files whose\r
+contents are tracked in\r
+your working tree and do corresponding <tt>git add</tt> and <tt>git rm</tt>\r
+for you. That is, this example does the same as the earlier\r
+example if there is no other change in your working tree:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ edit hello.c\r
+$ rm goodbye.c\r
+$ git commit -a</tt></pre>\r
+</div></div>\r
+<p>The command <tt>git commit -a</tt> first looks at your working tree,\r
+notices that you have modified hello.c and removed goodbye.c,\r
+and performs necessary <tt>git add</tt> and <tt>git rm</tt> for you.</p>\r
+<p>After staging changes to many files, you can alter the order the\r
+changes are recorded in, by giving pathnames to <tt>git commit</tt>.\r
+When pathnames are given, the command makes a commit that\r
+only records the changes made to the named paths:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ edit hello.c hello.h\r
+$ git add hello.c hello.h\r
+$ edit Makefile\r
+$ git commit Makefile</tt></pre>\r
+</div></div>\r
+<p>This makes a commit that records the modification to <tt>Makefile</tt>.\r
+The changes staged for <tt>hello.c</tt> and <tt>hello.h</tt> are not included\r
+in the resulting commit. However, their changes are not lost —\r
+they are still staged and merely held back. After the above\r
+sequence, if you do:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git commit</tt></pre>\r
+</div></div>\r
+<p>this second commit would record the changes to <tt>hello.c</tt> and\r
+<tt>hello.h</tt> as expected.</p>\r
+<p>After a merge (initiated by either <a href="git-merge.html">git-merge(1)</a> or\r
+<a href="git-pull.html">git-pull(1)</a>) stops because of conflicts, cleanly merged\r
+paths are already staged to be committed for you, and paths that\r
+conflicted are left in unmerged state. You would have to first\r
+check which paths are conflicting with <a href="git-status.html">git-status(1)</a>\r
+and after fixing them manually in your working tree, you would\r
+stage the result as usual with <a href="git-add.html">git-add(1)</a>:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git status | grep unmerged\r
+unmerged: hello.c\r
+$ edit hello.c\r
+$ git add hello.c</tt></pre>\r
+</div></div>\r
+<p>After resolving conflicts and staging the result, <tt>git ls-files -u</tt>\r
+would stop mentioning the conflicted path. When you are done,\r
+run <tt>git commit</tt> to finally record the merge:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git commit</tt></pre>\r
+</div></div>\r
+<p>As with the case to record your own changes, you can use <tt>-a</tt>\r
+option to save typing. One difference is that during a merge\r
+resolution, you cannot use <tt>git commit</tt> with pathnames to\r
+alter the order the changes are committed, because the merge\r
+should be recorded as a single commit. In fact, the command\r
+refuses to run when given pathnames (but see <tt>-i</tt> option).</p>\r
+</div>\r
+<h2>ENVIRONMENT VARIABLES</h2>\r
+<div class="sectionbody">\r
+<p>The command specified by either the VISUAL or EDITOR environment\r
+variables is used to edit the commit log message.</p>\r
+</div>\r
+<h2>HOOKS</h2>\r
+<div class="sectionbody">\r
+<p>This command can run <tt>commit-msg</tt>, <tt>pre-commit</tt>, and\r
+<tt>post-commit</tt> hooks. See <a href="hooks.html">hooks</a> for more\r
+information.</p>\r
+</div>\r
+<h2>SEE ALSO</h2>\r
+<div class="sectionbody">\r
+<p><a href="git-add.html">git-add(1)</a>,\r
+<a href="git-rm.html">git-rm(1)</a>,\r
+<a href="git-mv.html">git-mv(1)</a>,\r
+<a href="git-merge.html">git-merge(1)</a>,\r
+<a href="git-commit-tree.html">git-commit-tree(1)</a></p>\r
</div>\r
<h2>Author</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:40:57 UTC\r
+Last updated 13-Dec-2006 21:32:05 UTC\r
</div>\r
</div>\r
</body>\r
DESCRIPTION
-----------
-Updates the index file for given paths, or all modified files if
-'-a' is specified, and makes a commit object. The command specified
-by either the VISUAL or EDITOR environment variables are used to edit
-the commit log message.
+Use 'git commit' when you want to record your changes into the repository
+along with a log message describing what the commit is about. All changes
+to be committed must be explicitly identified using one of the following
+methods:
-Several environment variable are used during commits. They are
-documented in gitlink:git-commit-tree[1].
+1. by using gitlink:git-add[1] to incrementally "add" changes to the
+ 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
-------
-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.
+ Tell the command to automatically stage 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
-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`.
+--no-verify::
+ By default, the command looks for suspicious lines the
+ commit introduces, and aborts 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 option turns off the check.
-e|--edit::
The message taken from file with `-F`, command line with
--
-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
- behavior.
-
--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.
+ Before making a commit out of staged contents so far,
+ stage the contents of paths given on the command line
+ as well. This is usually not what you want unless you
+ are concluding a conflicted merge.
\--::
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].
+ When files are given on the command line, the command
+ commits the contents of the named files, without
+ recording the changes already staged. The contents of
+ these files are also staged for the next commit on top
+ of what have been staged before.
-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...`.
+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:
+
+------------
+$ edit hello.c
+$ git rm goodbye.c
+$ git add hello.c
+$ git commit
+------------
+
+////////////
+We should fix 'git rm' to remove goodbye.c from both index and
+working tree for the above example.
+////////////
+
+Instead of staging files after each individual change, you can
+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:
+
+------------
+$ edit hello.c
+$ rm goodbye.c
+$ git commit -a
+------------
+
+The command `git commit -a` first looks at your working tree,
+notices that you have modified hello.c and removed goodbye.c,
+and performs necessary `git add` and `git rm` for you.
+
+After staging changes to many files, you can alter the order the
+changes are recorded in, by giving pathnames to `git commit`.
+When pathnames are given, the command makes a commit that
+only records the changes made to the named paths:
+
+------------
+$ edit hello.c hello.h
+$ git add hello.c hello.h
+$ edit Makefile
+$ git commit Makefile
+------------
+
+This makes a commit that records the modification to `Makefile`.
+The changes staged for `hello.c` and `hello.h` are not included
+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
+------------
+
+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.
-`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.
+SEE ALSO
+--------
+gitlink:git-add[1],
+gitlink:git-rm[1],
+gitlink:git-mv[1],
+gitlink:git-merge[1],
+gitlink:git-commit-tree[1]
Author
------
<p>If "git-merge-index" is called with multiple <file>s (or -a) then it\r
processes them in turn only stopping if merge returns a non-zero exit\r
code.</p>\r
-<p>Typically this is run with the a script calling the merge command from\r
-the RCS package.</p>\r
+<p>Typically this is run with the a script calling git's imitation of\r
+the merge command from the RCS package.</p>\r
<p>A sample script called "git-merge-one-file" is included in the\r
distribution.</p>\r
<p>ALERT ALERT ALERT! The git "merge object order" is different from the\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:41:12 UTC\r
+Last updated 13-Dec-2006 21:32:05 UTC\r
</div>\r
</div>\r
</body>\r
processes them in turn only stopping if merge returns a non-zero exit
code.
-Typically this is run with the a script calling the merge command from
-the RCS package.
+Typically this is run with the a script calling git's imitation of
+the merge command from the RCS package.
A sample script called "git-merge-one-file" is included in the
distribution.
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-read-tree</em> (<tree-ish> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])</p>\r
+<p><em>git-read-tree</em> (<tree-ish> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</p>\r
</dd>\r
<dt>\r
+--exclude-per-directory=<gitignore>\r
+</dt>\r
+<dd>\r
+<p>\r
+ When running the command with <tt>-u</tt> and <tt>-m</tt> options, the\r
+ merge result may need to overwrite paths that are not\r
+ tracked in the current branch. The command usually\r
+ refuses to proceed with the merge to avoid losing such a\r
+ path. However this safety valve sometimes gets in the\r
+ way. For example, it often happens that the other\r
+ branch added a file that used to be a generated file in\r
+ your branch, and the safety valve triggers when you try\r
+ to switch to that branch after you ran <tt>make</tt> but before\r
+ running <tt>make clean</tt> to remove the generated file. This\r
+ option tells the command to read per-directory exclude\r
+ file (usually <em>.gitignore</em>) and allows such an untracked\r
+ but explicitly ignored file to be overwritten.\r
+</p>\r
+</dd>\r
+<dt>\r
<tree-ish#>\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:41:20 UTC\r
+Last updated 13-Dec-2006 21:32:06 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-read-tree' (<tree-ish> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+'git-read-tree' (<tree-ish> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
DESCRIPTION
directory. Note that the `<prefix>/` value must end
with a slash.
+--exclude-per-directory=<gitignore>::
+ When running the command with `-u` and `-m` options, the
+ merge result may need to overwrite paths that are not
+ tracked in the current branch. The command usually
+ refuses to proceed with the merge to avoid losing such a
+ path. However this safety valve sometimes gets in the
+ way. For example, it often happens that the other
+ branch added a file that used to be a generated file in
+ your branch, and the safety valve triggers when you try
+ to switch to that branch after you ran `make` but before
+ running `make clean` to remove the generated file. This
+ option tells the command to read per-directory exclude
+ file (usually '.gitignore') and allows such an untracked
+ but explicitly ignored file to be overwritten.
<tree-ish#>::
The id of the tree object(s) to be read/merged.
</p>\r
</dd>\r
<dt>\r
-color.pager\r
-</dt>\r
-<dd>\r
-<p>\r
- A boolean to enable/disable colored output when the pager is in\r
- use (default is true).\r
-</p>\r
-</dd>\r
-<dt>\r
color.diff\r
</dt>\r
<dd>\r
</p>\r
</dd>\r
<dt>\r
+color.pager\r
+</dt>\r
+<dd>\r
+<p>\r
+ A boolean to enable/disable colored output when the pager is in\r
+ use (default is true).\r
+</p>\r
+</dd>\r
+<dt>\r
+color.status\r
+</dt>\r
+<dd>\r
+<p>\r
+ A boolean to enable/disable color in the output of\r
+ <a href="git-status.html">git-status(1)</a>. May be set to <tt>true</tt> (or <tt>always</tt>),\r
+ <tt>false</tt> (or <tt>never</tt>) or <tt>auto</tt>, in which case colors are used\r
+ only when the output is to a terminal. Defaults to false.\r
+</p>\r
+</dd>\r
+<dt>\r
+color.status.<slot>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Use customized color for status colorization. <tt><slot></tt> is\r
+ one of <tt>header</tt> (the header text of the status message),\r
+ <tt>updated</tt> (files which are updated but not committed),\r
+ <tt>changed</tt> (files which are changed but not updated in the index),\r
+ or <tt>untracked</tt> (files which are not tracked by git). The values of\r
+ these variables may be specified as in color.diff.<slot>.\r
+</p>\r
+</dd>\r
+<dt>\r
diff.renameLimit\r
</dt>\r
<dd>\r
</p>\r
</dd>\r
<dt>\r
-color.status\r
-</dt>\r
-<dd>\r
-<p>\r
- A boolean to enable/disable color in the output of\r
- <a href="git-status.html">git-status(1)</a>. May be set to <tt>true</tt> (or <tt>always</tt>),\r
- <tt>false</tt> (or <tt>never</tt>) or <tt>auto</tt>, in which case colors are used\r
- only when the output is to a terminal. Defaults to false.\r
-</p>\r
-</dd>\r
-<dt>\r
-color.status.<slot>\r
-</dt>\r
-<dd>\r
-<p>\r
- Use customized color for status colorization. <tt><slot></tt> is\r
- one of <tt>header</tt> (the header text of the status message),\r
- <tt>updated</tt> (files which are updated but not committed),\r
- <tt>changed</tt> (files which are changed but not updated in the index),\r
- or <tt>untracked</tt> (files which are not tracked by git). The values of\r
- these variables may be specified as in color.diff.<slot>.\r
-</p>\r
-</dd>\r
-<dt>\r
tar.umask\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 13-Dec-2006 10:14:08 UTC\r
+Last updated 13-Dec-2006 21:32:06 UTC\r
</div>\r
</div>\r
</body>\r
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-rerere</em></p>\r
+<p><em>git-rerere</em> [clear|diff|status]</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</tr></table>\r
</div>\r
</div>\r
+<h2>COMMANDS</h2>\r
+<div class="sectionbody">\r
+<p>Normally, git-rerere is run without arguments or user-intervention.\r
+However, it has several commands that allow it to interact with\r
+its working state.</p>\r
+<dl>\r
+<dt>\r
+<em>clear</em>\r
+</dt>\r
+<dd>\r
+<p>\r
+This resets the metadata used by rerere if a merge resolution is to be\r
+is aborted. Calling <a href="git-am.html">git-am(1)</a> --skip or <a href="git-rebase.html">git-rebase(1)</a>\r
+[--skip|--abort] will automatcally invoke this command.\r
+</p>\r
+</dd>\r
+<dt>\r
+<em>diff</em>\r
+</dt>\r
+<dd>\r
+<p>\r
+This displays diffs for the current state of the resolution. It is\r
+useful for tracking what has changed while the user is resolving\r
+conflicts. Additional arguments are passed directly to the system\r
+diff(1) command installed in PATH.\r
+</p>\r
+</dd>\r
+<dt>\r
+<em>status</em>\r
+</dt>\r
+<dd>\r
+<p>\r
+Like diff, but this only prints the filenames that will be tracked\r
+for resolutions.\r
+</p>\r
+</dd>\r
+<dt>\r
+<em>gc</em>\r
+</dt>\r
+<dd>\r
+<p>\r
+This command is used to prune records of conflicted merge that\r
+occurred long time ago.\r
+</p>\r
+</dd>\r
+</dl>\r
+</div>\r
<h2>DISCUSSION</h2>\r
<div class="sectionbody">\r
<p>When your topic branch modifies overlapping area that your\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:41:23 UTC\r
+Last updated 13-Dec-2006 21:32:08 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-rerere'
-
+'git-rerere' [clear|diff|status]
DESCRIPTION
-----------
You need to create `$GIT_DIR/rr-cache` directory to enable this
command.
+
+COMMANDS
+--------
+
+Normally, git-rerere is run without arguments or user-intervention.
+However, it has several commands that allow it to interact with
+its working state.
+
+'clear'::
+
+This resets the metadata used by rerere if a merge resolution is to be
+is aborted. Calling gitlink:git-am[1] --skip or gitlink:git-rebase[1]
+[--skip|--abort] will automatcally invoke this command.
+
+'diff'::
+
+This displays diffs for the current state of the resolution. It is
+useful for tracking what has changed while the user is resolving
+conflicts. Additional arguments are passed directly to the system
+diff(1) command installed in PATH.
+
+'status'::
+
+Like diff, but this only prints the filenames that will be tracked
+for resolutions.
+
+'gc'::
+
+This command is used to prune records of conflicted merge that
+occurred long time ago.
+
+
DISCUSSION
----------
$ git add .\r
$ git commit -a -m "initial commit"\r
Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe\r
+ create mode 100644 file.txt\r
$ echo 'hello world!' >file.txt\r
$ git commit -a -m "add emphasis"</tt></pre>\r
</div></div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:41:43 UTC\r
+Last updated 13-Dec-2006 21:32:09 UTC\r
</div>\r
</div>\r
</body>\r
$ git add .
$ git commit -a -m "initial commit"
Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
+ create mode 100644 file.txt
$ echo 'hello world!' >file.txt
$ git commit -a -m "add emphasis"
------------------------------------------------
thorough description. Tools that turn commits into email, for\r
example, use the first line on the Subject line and the rest of the\r
commit in the body.</p>\r
-<p>To add a new file, first create the file, then</p>\r
-<div class="listingblock">\r
-<div class="content">\r
-<pre><tt>$ git add path/to/new/file</tt></pre>\r
-</div></div>\r
-<p>then commit as usual. No special command is required when removing a\r
-file; just remove it, then tell <tt>commit</tt> about the file as usual.</p>\r
+</div>\r
+<h2>Git tracks content not files</h2>\r
+<div class="sectionbody">\r
+<p>With git you have to explicitly "add" all the changed _content_ you\r
+want to commit together. This can be done in a few different ways:</p>\r
+<p>1) By using <em>git add <file_spec>…</em></p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>This can be performed multiple times before a commit. Note that this\r
+is not only for adding new files. Even modified files must be\r
+added to the set of changes about to be committed. The "git status"\r
+command gives you a summary of what is included so far for the\r
+next commit. When done you should use the 'git commit' command to\r
+make it real.</tt></pre>\r
+</div></div>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>Note: don't forget to 'add' a file again if you modified it after the\r
+first 'add' and before 'commit'. Otherwise only the previous added\r
+state of that file will be committed. This is because git tracks\r
+content, so what you're really 'add'ing to the commit is the *content*\r
+of the file in the state it is in when you 'add' it.</tt></pre>\r
+</div></div>\r
+<p>2) By using <em>git commit -a</em> directly</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>This is a quick way to automatically 'add' the content from all files\r
+that were modified since the previous commit, and perform the actual\r
+commit without having to separately 'add' them beforehand. This will\r
+not add content from new files i.e. files that were never added before.\r
+Those files still have to be added explicitly before performing a\r
+commit.</tt></pre>\r
+</div></div>\r
+<p>But here's a twist. If you do <em>git commit <file1> <file2> …</em> then only\r
+the changes belonging to those explicitly specified files will be\r
+committed, entirely bypassing the current "added" changes. Those "added"\r
+changes will still remain available for a subsequent commit though.</p>\r
+<p>However, for normal usage you only have to remember <em>git add</em> + <em>git commit</em>\r
+and/or <em>git commit -a</em>.</p>\r
+</div>\r
+<h2>Viewing the changelog</h2>\r
+<div class="sectionbody">\r
<p>At any point you can view the history of your changes using</p>\r
<div class="listingblock">\r
<div class="content">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 29-Nov-2006 20:40:00 UTC\r
+Last updated 13-Dec-2006 21:32:08 UTC\r
</div>\r
</div>\r
</body>\r
example, use the first line on the Subject line and the rest of the
commit in the body.
-To add a new file, first create the file, then
-------------------------------------------------
-$ git add path/to/new/file
-------------------------------------------------
+Git tracks content not files
+----------------------------
+
+With git you have to explicitly "add" all the changed _content_ you
+want to commit together. This can be done in a few different ways:
+
+1) By using 'git add <file_spec>...'
+
+ This can be performed multiple times before a commit. Note that this
+ is not only for adding new files. Even modified files must be
+ added to the set of changes about to be committed. The "git status"
+ command gives you a summary of what is included so far for the
+ next commit. When done you should use the 'git commit' command to
+ make it real.
+
+ Note: don't forget to 'add' a file again if you modified it after the
+ first 'add' and before 'commit'. Otherwise only the previous added
+ state of that file will be committed. This is because git tracks
+ content, so what you're really 'add'ing to the commit is the *content*
+ of the file in the state it is in when you 'add' it.
+
+2) By using 'git commit -a' directly
+
+ This is a quick way to automatically 'add' the content from all files
+ that were modified since the previous commit, and perform the actual
+ commit without having to separately 'add' them beforehand. This will
+ not add content from new files i.e. files that were never added before.
+ Those files still have to be added explicitly before performing a
+ commit.
+
+But here's a twist. If you do 'git commit <file1> <file2> ...' then only
+the changes belonging to those explicitly specified files will be
+committed, entirely bypassing the current "added" changes. Those "added"
+changes will still remain available for a subsequent commit though.
+
+However, for normal usage you only have to remember 'git add' + 'git commit'
+and/or 'git commit -a'.
+
-then commit as usual. No special command is required when removing a
-file; just remove it, then tell `commit` about the file as usual.
+Viewing the changelog
+---------------------
At any point you can view the history of your changes using