Autogenerated HTML docs for v1.4.4.2-g1d77
authorJunio C Hamano <junio@hera.kernel.org>
Wed, 13 Dec 2006 21:32:17 +0000 (21:32 +0000)
committerJunio C Hamano <junio@hera.kernel.org>
Wed, 13 Dec 2006 21:32:17 +0000 (21:32 +0000)
18 files changed:
config.txt
git-add.html
git-add.txt
git-branch.html
git-branch.txt
git-commit.html
git-commit.txt
git-merge-index.html
git-merge-index.txt
git-read-tree.html
git-read-tree.txt
git-repo-config.html
git-rerere.html
git-rerere.txt
tutorial-2.html
tutorial-2.txt
tutorial.html
tutorial.txt

index f5a552ee8722dc0e18265164fd6a6b344d691d57..a3587f83970cf3c7b84b31aa6e90e0dbfb476d65 100644 (file)
@@ -137,10 +137,6 @@ branch.<name>.merge::
        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
@@ -157,6 +153,24 @@ color.diff.<slot>::
        `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'.
@@ -271,20 +285,6 @@ showbranch.default::
        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
index 54254fa19f4366489ea3e6bbfabdb12deb10b1a9..b43876537a9013eecbbf513768543832c2b0280c 100644 (file)
@@ -266,7 +266,7 @@ git-add(1) Manual Page
 <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
@@ -276,10 +276,21 @@ git-add(1) Manual Page
 </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
@@ -289,7 +300,7 @@ for people used to do "cvs add".</p>
 </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
@@ -320,27 +331,6 @@ for people used to do "cvs add".</p>
 </dd>\r
 </dl>\r
 </div>\r
-<h2>DISCUSSION</h2>\r
-<div class="sectionbody">\r
-<p>The list of &lt;file&gt; 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
@@ -349,8 +339,8 @@ git-add Documentation/\*.txt
 </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
@@ -361,18 +351,21 @@ git-add git-*.sh
 </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
@@ -388,7 +381,7 @@ git-add git-*.sh
 </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
index 6342ea33e4a34f19ca04c79157d80cb230c15f5c..d86c0e7f19ee67556b48bb7f94ab9039a0195ea6 100644 (file)
@@ -3,7 +3,7 @@ git-add(1)
 
 NAME
 ----
-git-add - Add files to the index file
+git-add - Add file contents to the changeset to be committed next
 
 SYNOPSIS
 --------
@@ -11,16 +11,31 @@ 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.
@@ -34,27 +49,12 @@ OPTIONS
        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
@@ -62,15 +62,18 @@ subdirectories of `Documentation/` directory.
 
 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
 ------
index 486778935b4a554e2454fd8bb0bb49deed8eb00e..74a4e26d1361b7b4d41b80e636ad3a276a0adc93 100644 (file)
@@ -273,8 +273,9 @@ git-branch(1) Manual Page
 <h2>SYNOPSIS</h2>\r
 <div class="sectionbody">\r
 <div class="verseblock">\r
-<div class="content"><em>git-branch</em> [-r] [-a] [-v] [--abbrev=&lt;length&gt;]\r
+<div class="content"><em>git-branch</em> [-r | -a] [-v [--abbrev=&lt;length&gt;]]\r
 <em>git-branch</em> [-l] [-f] &lt;branchname&gt; [&lt;start-point&gt;]\r
+<em>git-branch</em> (-m | -M) [&lt;oldbranch&gt;] &lt;newbranch&gt;\r
 <em>git-branch</em> (-d | -D) &lt;branchname&gt;&#8230;</div></div>\r
 </div>\r
 <h2>DESCRIPTION</h2>\r
@@ -287,6 +288,11 @@ and option <tt>-a</tt> shows both.</p>
 It will start out with a head equal to the one given as &lt;start-point&gt;.\r
 If no &lt;start-point&gt; 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, &lt;oldbranch&gt; will be renamed to &lt;newbranch&gt;.\r
+If &lt;oldbranch&gt; had a corresponding reflog, it is renamed to match\r
+&lt;newbranch&gt;, and a reflog entry is created to remember the branch\r
+renaming. If &lt;newbranch&gt; 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>&lt;branchname&gt;</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
@@ -329,6 +335,22 @@ has a ref log then the ref log will also be deleted.</p>
 </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
@@ -349,7 +371,7 @@ has a ref log then the ref log will also be deleted.</p>
 </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
@@ -382,6 +404,23 @@ has a ref log then the ref log will also be deleted.</p>
         is omitted, the current branch is assumed.\r
 </p>\r
 </dd>\r
+<dt>\r
+&lt;oldbranch&gt;\r
+</dt>\r
+<dd>\r
+<p>\r
+        The name of an existing branch to rename.\r
+</p>\r
+</dd>\r
+<dt>\r
+&lt;newbranch&gt;\r
+</dt>\r
+<dd>\r
+<p>\r
+        The new name for an existing branch. The same restrictions as for\r
+        &lt;branchname&gt; applies.\r
+</p>\r
+</dd>\r
 </dl>\r
 </div>\r
 <h2>Examples</h2>\r
@@ -448,7 +487,7 @@ a branch and check it out with a single command.</p>
 </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
index 4f5b5d5028e15f693440baa57358ab4c898994e8..71417feba8f4987bb9d7565ec58f82044d343283 100644 (file)
@@ -8,8 +8,9 @@ git-branch - List, create, or delete branches.
 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
@@ -24,6 +25,12 @@ It will start out with a head equal to the one given as <start-point>.
 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.
@@ -46,6 +53,12 @@ OPTIONS
        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.
 
@@ -53,7 +66,7 @@ OPTIONS
        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,
@@ -70,6 +83,12 @@ OPTIONS
        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
index 8d8a943376baac786e752ec9b0d0af37dfed6db7..b163557dec5a175f545fedabc67bda18fb8a53df 100644 (file)
@@ -279,15 +279,45 @@ git-commit(1) Manual Page
 </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
@@ -297,9 +327,9 @@ information.</p>
 </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
@@ -349,24 +379,16 @@ information.</p>
 </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
@@ -409,21 +431,10 @@ information.</p>
 </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
@@ -439,62 +450,115 @@ information.</p>
 </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&#8230;</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&#8230;</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&#8230;</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&#8230;</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&#8230;</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&#8230;</tt> and makes a commit.  At the same time,\r
-  the real index file is also updated with the same <tt>paths&#8230;</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 &#8212;\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
@@ -507,7 +571,7 @@ Junio C Hamano &lt;junkio@cox.net&gt;</p>
 </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
index 517a86b238a91a1c853b5fbe331a5cc984e95878..97d66ef4d2c982706be98eaaea056107694e8d8c 100644 (file)
@@ -14,25 +14,41 @@ SYNOPSIS
 
 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
@@ -55,16 +71,13 @@ OPTIONS
 -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
@@ -95,69 +108,137 @@ but can be used to amend a merge commit.
 --
 
 -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
 ------
index 91fedf022ebce4506572f25909f45c5b9878dab9..e7eeeaff0cdb90015c6692e59d7cd1dd0285c3af 100644 (file)
@@ -325,8 +325,8 @@ files are passed as arguments 5, 6 and 7.</p>
 <p>If "git-merge-index" is called with multiple &lt;file&gt;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
@@ -372,7 +372,7 @@ One-shot merge by Petr Baudis &lt;pasky@ucw.cz&gt;</p>
 </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
index 6cd060108292733725aca28cc8f0b83aa7d0f56e..0cf505ea84d231e4e4997676d4169c5c5c7dd9f9 100644 (file)
@@ -40,8 +40,8 @@ If "git-merge-index" is called with multiple <file>s (or -a) then it
 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.
index bc765eade27f6f59f75af7f4921fcca4a42d0196..1bdc82741dd1a86f0feef209c41574f53dc83bdd 100644 (file)
@@ -272,7 +272,7 @@ git-read-tree(1) Manual Page
 </div>\r
 <h2>SYNOPSIS</h2>\r
 <div class="sectionbody">\r
-<p><em>git-read-tree</em> (&lt;tree-ish&gt; | [[-m [--aggressive] | --reset | --prefix=&lt;prefix&gt;] [-u | -i]] &lt;tree-ish1&gt; [&lt;tree-ish2&gt; [&lt;tree-ish3&gt;]])</p>\r
+<p><em>git-read-tree</em> (&lt;tree-ish&gt; | [[-m [--aggressive] | --reset | --prefix=&lt;prefix&gt;] [-u | -i]] [--exclude-per-directory=&lt;gitignore&gt;] &lt;tree-ish1&gt; [&lt;tree-ish2&gt; [&lt;tree-ish3&gt;]])</p>\r
 </div>\r
 <h2>DESCRIPTION</h2>\r
 <div class="sectionbody">\r
@@ -377,6 +377,26 @@ when both sides adds a path identically.  The resolution
 </p>\r
 </dd>\r
 <dt>\r
+--exclude-per-directory=&lt;gitignore&gt;\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
 &lt;tree-ish#&gt;\r
 </dt>\r
 <dd>\r
@@ -662,7 +682,7 @@ have finished your work-in-progress), attempt the merge again.</p>
 </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
index 11bd9c0adc5517ef1aadc76abdb8dfb0827c27b0..0ff2890c7fb76155e08eaf9e361bf1eb6cf50f25 100644 (file)
@@ -8,7 +8,7 @@ git-read-tree - Reads tree information into the index
 
 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
@@ -71,6 +71,20 @@ OPTIONS
        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.
index 8935bb954e33669006e65fa05c77d2df60131ddc..bdeb43ebb5cdb9878561386da72d2d917afc57a0 100644 (file)
@@ -748,15 +748,6 @@ branch.&lt;name&gt;.merge
 </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
@@ -783,6 +774,39 @@ color.diff.&lt;slot&gt;
 </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.&lt;slot&gt;\r
+</dt>\r
+<dd>\r
+<p>\r
+        Use customized color for status colorization. <tt>&lt;slot&gt;</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.&lt;slot&gt;.\r
+</p>\r
+</dd>\r
+<dt>\r
 diff.renameLimit\r
 </dt>\r
 <dd>\r
@@ -1022,30 +1046,6 @@ showbranch.default
 </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.&lt;slot&gt;\r
-</dt>\r
-<dd>\r
-<p>\r
-        Use customized color for status colorization. <tt>&lt;slot&gt;</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.&lt;slot&gt;.\r
-</p>\r
-</dd>\r
-<dt>\r
 tar.umask\r
 </dt>\r
 <dd>\r
@@ -1140,7 +1140,7 @@ receive.denyNonFastForwards
 </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
index e311b6170b2be55ac1ea7a694dc1338c952adc56..aee041597d2c2d183f6d8db4ea20ed4c971c3984 100644 (file)
@@ -272,7 +272,7 @@ git-rerere(1) Manual Page
 </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
@@ -294,6 +294,53 @@ command.</td>
 </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
@@ -431,7 +478,7 @@ conflict.</p>
 </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
index 8b6b6512371fd67fbb56d06cf29e826d3ef69d56..116dca4c0668488a0ba55b43a10e89c40f087b59 100644 (file)
@@ -7,8 +7,7 @@ git-rerere - Reuse recorded resolve
 
 SYNOPSIS
 --------
-'git-rerere'
-
+'git-rerere' [clear|diff|status]
 
 DESCRIPTION
 -----------
@@ -27,6 +26,38 @@ results and applying the previously recorded hand resolution.
 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
 ----------
 
index c092d0eb915f1d489253f1387468204f67d9cbc4..c954b77ebeeccbd18c27e3db7e69e6365564e11b 100644 (file)
@@ -284,6 +284,7 @@ $ echo 'hello world' &gt; file.txt
 $ git add .\r
 $ git commit -a -m "initial commit"\r
 Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe\r
+ create mode 100644 file.txt\r
 $ echo 'hello world!' &gt;file.txt\r
 $ git commit -a -m "add emphasis"</tt></pre>\r
 </div></div>\r
@@ -635,7 +636,7 @@ example, creating a new commit.</p>
 </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
index 42b6e7d7d2bbb24d96f29635967945f516b25e15..6389de5ef7e221d84bb9c5443af09fb62960de4c 100644 (file)
@@ -23,6 +23,7 @@ $ echo 'hello world' > file.txt
 $ 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"
 ------------------------------------------------
index 77b3f79d648150747a48d149a1aef4a033645ab5..5a7fa51c9fb9eab67dd1680a3fddc1aff17903fc 100644 (file)
@@ -337,13 +337,48 @@ line summarizing the change, followed by a blank line and then a more
 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 &lt;file_spec&gt;&#8230;</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 &lt;file1&gt; &lt;file2&gt; &#8230;</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
@@ -727,7 +762,7 @@ digressions that may be interesting at this point are:</p>
 </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
index fe4491de41d1bcaeb56d5152e580eb483b0a12b0..02dede320ca9ddff4a9de0c5bb273bdf5eff9e74 100644 (file)
@@ -87,14 +87,48 @@ thorough description.  Tools that turn commits into email, for
 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