Autogenerated HTML docs for v1.5.3-rc0-63-gc956

diff --git a/config.txt b/config.txt
index 66a55b0514b3a1427792f3e2865f34bc642e1e48..4b67f0adf721d540ddd437254de4aa069f1be0ae 100644 (file)
--- a/config.txt
+++ b/config.txt
@@ -448,6 +448,11 @@ gc.rerereunresolved::
        kept for this many days when `git rerere gc` is run.
        The default is 15 days.  See gitlink:git-rerere[1].
 
+rerere.enabled::
+       Activate recording of resolved conflicts, so that identical
+       conflict hunks can be resolved automatically, should they
+       be encountered again.  See gitlink:git-rerere[1].
+
 gitcvs.enabled::
        Whether the cvs server interface is enabled for this repository.
        See gitlink:git-cvsserver[1].

diff --git a/core-intro.txt b/core-intro.txt
index eea44d9d5613f448b8c2b8f0aae236f917efad39..f3cc2238c72d11e611a756e366d797c9d8056111 100644 (file)
--- a/core-intro.txt
+++ b/core-intro.txt
@@ -528,7 +528,7 @@ paths that have been trivially merged.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
+been added, moved or removed, or if both branches have modified the
 same file, you will be left with an index tree that contains "merge
 entries" in it. Such an index tree can 'NOT' be written out to a tree
 object, and you will have to resolve any such merge clashes using

diff --git a/git-config.html b/git-config.html
index eec0eef814df0a6a99ef21d625c5c9aa0ea47837..5e46547f91abf1917a41c306359b0c852e72dd22 100644 (file)
--- a/git-config.html
+++ b/git-config.html
@@ -1305,6 +1305,16 @@ gc.rerereunresolved
 </p>\r
 </dd>\r
 <dt>\r
+rerere.enabled\r
+</dt>\r
+<dd>\r
+<p>\r
+        Activate recording of resolved conflicts, so that identical\r
+        conflict hunks can be resolved automatically, should they\r
+        be encountered again.  See <a href="git-rerere.html">git-rerere(1)</a>.\r
+</p>\r
+</dd>\r
+<dt>\r
 gitcvs.enabled\r
 </dt>\r
 <dd>\r
@@ -1829,7 +1839,7 @@ transfer.unpackLimit
 </div>\r
 <div id="footer">\r
 <div id="footer-text">\r
-Last updated 05-Jul-2007 05:51:15 UTC\r
+Last updated 07-Jul-2007 21:52:19 UTC\r
 </div>\r
 </div>\r
 </body>\r

diff --git a/git-rerere.html b/git-rerere.html
index 7caf338cef313e7bf9d61ae8ba954a13ac80a63b..408717023c3b676849c40d12f8e72f974e4f60a8 100644 (file)
--- a/git-rerere.html
+++ b/git-rerere.html
@@ -289,7 +289,7 @@ results and applying the previously recorded hand resolution.</p>
 <td class="icon">\r
 <div class="title">Note</div>\r
 </td>\r
-<td class="content">You need to create <tt>$GIT_DIR/rr-cache</tt> directory to enable this\r
+<td class="content">You need to set the config variable rerere.enabled to enable this\r
 command.</td>\r
 </tr></table>\r
 </div>\r
@@ -444,7 +444,7 @@ records it if it is a new conflict, or reuses the earlier hand
 resolve when it is not.  <tt>git-commit</tt> also invokes <tt>git-rerere</tt>\r
 when recording a merge result.  What this means is that you do\r
 not have to do anything special yourself (Note: you still have\r
-to create <tt>$GIT_DIR/rr-cache</tt> directory to enable this command).</p>\r
+to set the config variable rerere.enabled to enable this command).</p>\r
 <p>In our example, when you did the test merge, the manual\r
 resolution is recorded, and it will be reused when you do the\r
 actual merge later with updated master and topic branch, as long\r
@@ -481,7 +481,7 @@ conflict.</p>
 </div>\r
 <div id="footer">\r
 <div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:19 UTC\r
+Last updated 07-Jul-2007 21:52:19 UTC\r
 </div>\r
 </div>\r
 </body>\r

diff --git a/git-rerere.txt b/git-rerere.txt
index 7ff9b05e680cabc6513f9d8a6aa80eb7eccda82d..c4d4263238e5b7c6dff705de5d8552a577fc35d6 100644 (file)
--- a/git-rerere.txt
+++ b/git-rerere.txt
@@ -23,7 +23,7 @@ initial manual merge, and later by noticing the same automerge
 results and applying the previously recorded hand resolution.
 
 [NOTE]
-You need to create `$GIT_DIR/rr-cache` directory to enable this
+You need to set the config variable rerere.enabled to enable this
 command.
 
 
@@ -171,7 +171,7 @@ records it if it is a new conflict, or reuses the earlier hand
 resolve when it is not.  `git-commit` also invokes `git-rerere`
 when recording a merge result.  What this means is that you do
 not have to do anything special yourself (Note: you still have
-to create `$GIT_DIR/rr-cache` directory to enable this command).
+to set the config variable rerere.enabled to enable this command).
 
 In our example, when you did the test merge, the manual
 resolution is recorded, and it will be reused when you do the

diff --git a/git-submodule.html b/git-submodule.html
index b7243732eebd4e7627b7794a556fdf3ef625364c..7d587999fcc4b0a0d36e9a6d039f1b706db91e1e 100644 (file)
--- a/git-submodule.html
+++ b/git-submodule.html
@@ -272,8 +272,9 @@ git-submodule(1) Manual Page
 </div>\r
 <h2>SYNOPSIS</h2>\r
 <div class="sectionbody">\r
-<p><em>git-submodule</em> [--quiet] [-b branch] add &lt;repository&gt; [&lt;path&gt;]\r
-<em>git-submodule</em> [--quiet] [--cached] [status|init|update] [--] [&lt;path&gt;&#8230;]</p>\r
+<div class="verseblock">\r
+<div class="content"><em>git-submodule</em> [--quiet] [-b branch] add &lt;repository&gt; [&lt;path&gt;]\r
+<em>git-submodule</em> [--quiet] [--cached] [status|init|update] [--] [&lt;path&gt;&#8230;]</div></div>\r
 </div>\r
 <h2>COMMANDS</h2>\r
 <div class="sectionbody">\r
@@ -310,8 +311,8 @@ init
 <dd>\r
 <p>\r
         Initialize the submodules, i.e. register in .git/config each submodule\r
-        path and url found in .gitmodules. The key used in git/config is\r
-        <tt>submodule.$path.url</tt>. This command does not alter existing information\r
+        name and url found in .gitmodules. The key used in .git/config is\r
+        <tt>submodule.$name.url</tt>. This command does not alter existing information\r
         in .git/config.\r
 </p>\r
 </dd>\r
@@ -372,7 +373,7 @@ update
 <p>When initializing submodules, a .gitmodules file in the top-level directory\r
 of the containing repository is used to find the url of each submodule.\r
 This file should be formatted in the same way as $GIR_DIR/config. The key\r
-to each submodule url is "module.$path.url".</p>\r
+to each submodule url is "submodule.$name.url".</p>\r
 </div>\r
 <h2>AUTHOR</h2>\r
 <div class="sectionbody">\r
@@ -384,7 +385,7 @@ to each submodule url is "module.$path.url".</p>
 </div>\r
 <div id="footer">\r
 <div id="footer-text">\r
-Last updated 03-Jul-2007 07:03:46 UTC\r
+Last updated 07-Jul-2007 21:52:20 UTC\r
 </div>\r
 </div>\r
 </body>\r

diff --git a/git-submodule.txt b/git-submodule.txt
index 7f0904e2933613e1da2312bec28682d3accf2a1d..2c48936fcd72c5276ae2fed217bd9b9564342f03 100644 (file)
--- a/git-submodule.txt
+++ b/git-submodule.txt
@@ -8,6 +8,7 @@ git-submodule - Initialize, update or inspect submodules
 
 SYNOPSIS
 --------
+[verse]
 'git-submodule' [--quiet] [-b branch] add <repository> [<path>]
 'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
 
@@ -32,8 +33,8 @@ status::
 
 init::
        Initialize the submodules, i.e. register in .git/config each submodule
-       path and url found in .gitmodules. The key used in git/config is
-       `submodule.$path.url`. This command does not alter existing information
+       name and url found in .gitmodules. The key used in .git/config is
+       `submodule.$name.url`. This command does not alter existing information
        in .git/config.
 
 update::
@@ -64,7 +65,7 @@ FILES
 When initializing submodules, a .gitmodules file in the top-level directory
 of the containing repository is used to find the url of each submodule.
 This file should be formatted in the same way as $GIR_DIR/config. The key
-to each submodule url is "module.$path.url".
+to each submodule url is "submodule.$name.url".
 
 
 AUTHOR

diff --git a/git.html b/git.html
index 427496174e64f0227267bbfe6186b974393f5e8f..b55f52c09789c0b264d6a93380fc4b4f4108ab92 100644 (file)
--- a/git.html
+++ b/git.html
@@ -2301,7 +2301,7 @@ option, updates your working tree with the merge results for
 paths that have been trivially merged.</p>\r
 <h3>8) Merging multiple trees, continued</h3>\r
 <p>Sadly, many merges aren't trivial. If there are files that have\r
-been added.moved or removed, or if both branches have modified the\r
+been added, moved or removed, or if both branches have modified the\r
 same file, you will be left with an index tree that contains "merge\r
 entries" in it. Such an index tree can <em>NOT</em> be written out to a tree\r
 object, and you will have to resolve any such merge clashes using\r
@@ -2398,7 +2398,7 @@ contributors on the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>\r
 <div id="footer">\r
 <div id="footer-text">\r
-Last updated 04-Jul-2007 06:40:55 UTC\r
+Last updated 07-Jul-2007 21:52:21 UTC\r
 </div>\r
 </div>\r
 </body>\r

diff --git a/user-manual.html b/user-manual.html
index e08c53150604ed04ea6facbff7d72bd401a43754..0e605b6074a2d24ed418f7e4bc0dd8fd0d707e43 100644 (file)
--- a/user-manual.html
+++ b/user-manual.html
@@ -1246,13 +1246,13 @@ cache, and the normal operation is to re-generate it completely from a
 known tree object, or update/compare it with a live tree that is being
 developed.  If you blow the directory cache away entirely, you generally
 haven't lost any information as long as you have the name of the tree
-that it described.</p><p>At the same time, the index is at the same time also the
-staging area for creating new trees, and creating a new tree always
-involves a controlled modification of the index file.  In particular,
-the index file can have the representation of an intermediate tree that
-has not yet been instantiated.  So the index can be thought of as a
-write-back cache, which can contain dirty information that has not yet
-been written back to the backing store.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="the-workflow"></a>The Workflow</h2></div></div></div><p>Generally, all "git" operations work on the index file. Some operations
+that it described.</p><p>At the same time, the index is also the staging area for creating
+new trees, and creating a new tree always involves a controlled
+modification of the index file.  In particular, the index file can
+have the representation of an intermediate tree that has not yet been
+instantiated.  So the index can be thought of as a write-back cache,
+which can contain dirty information that has not yet been written back
+to the backing store.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="the-workflow"></a>The Workflow</h2></div></div></div><p>Generally, all "git" operations work on the index file. Some operations
 work <span class="strong"><strong>purely</strong></span> on the index file (showing the current state of the
 index), but most operations move data to and from the index file. Either
 from the database or from the working directory. Thus there are four

diff --git a/user-manual.txt b/user-manual.txt
index ff7c71d4fb73932dd0925cf9dd19c74544f68055..c23077c724a6a22eee87018961d8435ffe3c0126 100644 (file)
--- a/user-manual.txt
+++ b/user-manual.txt
@@ -2957,13 +2957,13 @@ developed.  If you blow the directory cache away entirely, you generally
 haven't lost any information as long as you have the name of the tree
 that it described.
 
-At the same time, the index is at the same time also the
-staging area for creating new trees, and creating a new tree always
-involves a controlled modification of the index file.  In particular,
-the index file can have the representation of an intermediate tree that
-has not yet been instantiated.  So the index can be thought of as a
-write-back cache, which can contain dirty information that has not yet
-been written back to the backing store.
+At the same time, the index is also the staging area for creating
+new trees, and creating a new tree always involves a controlled
+modification of the index file.  In particular, the index file can
+have the representation of an intermediate tree that has not yet been
+instantiated.  So the index can be thought of as a write-back cache,
+which can contain dirty information that has not yet been written back
+to the backing store.