Autogenerated HTML docs for v1.4.0-rc1
[git.git] / git-read-tree.html
index a5bd09f..d159a4c 100644 (file)
@@ -3,7 +3,7 @@
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
 <head>\r
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />\r
-<meta name="generator" content="AsciiDoc 7.0.1" />\r
+<meta name="generator" content="AsciiDoc 7.0.2" />\r
 <style type="text/css">\r
 /* Debug borders */\r
 p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {\r
@@ -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 | --reset] [-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] [-u | -i]] &lt;tree-ish1&gt; [&lt;tree-ish2&gt; [&lt;tree-ish3&gt;]])</p>\r
 </div>\r
 <h2>DESCRIPTION</h2>\r
 <div class="sectionbody">\r
@@ -333,6 +333,37 @@ will be in unmerged state when <tt>git-read-tree</tt> returns.</p>
 </p>\r
 </dd>\r
 <dt>\r
+--aggressive\r
+</dt>\r
+<dd>\r
+<p>\r
+        Usually a three-way merge by <tt>git-read-tree</tt> resolves\r
+        the merge for really trivial cases and leaves other\r
+        cases unresolved in the index, so that Porcelains can\r
+        implement different merge policies.  This flag makes the\r
+        command to resolve a few more cases internally:\r
+</p>\r
+<ul>\r
+<li>\r
+<p>\r
+when one side removes a path and the other side leaves the path\r
+  unmodified.  The resolution is to remove that path.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+when both sides remove a path.  The resolution is to remove that path.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+when both sides adds a path identically.  The resolution\r
+  is to add that path.\r
+</p>\r
+</li>\r
+</ul>\r
+</dd>\r
+<dt>\r
 &lt;tree-ish#&gt;\r
 </dt>\r
 <dd>\r
@@ -489,7 +520,7 @@ stage 1 and stage 3 are the same and stage 2 is different take
 <p>The <tt>git-write-tree</tt> command refuses to write a nonsensical tree, and it\r
 will complain about unmerged entries if it sees a single entry that is not\r
 stage 0.</p>\r
-<p>Ok, this all sounds like a collection of totally nonsensical rules,\r
+<p>OK, this all sounds like a collection of totally nonsensical rules,\r
 but it's actually exactly what you want in order to do a fast\r
 merge. The different stages represent the "result tree" (stage 0, aka\r
 "merged"), the original tree (stage 1, aka "orig"), and the two trees\r
@@ -517,7 +548,7 @@ a file that has _any_ difference what-so-ever in the three trees
 <p>\r
 the index file saves and restores with all this information, so you\r
   can merge things incrementally, but as long as it has entries in\r
-  stages 1/2/3 (ie "unmerged entries") you can't write the result. So\r
+  stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So\r
   now the merge algorithm ends up being really simple:\r
 </p>\r
 <ul>\r
@@ -618,7 +649,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 27-Dec-2005 00:16:31 PDT\r
+Last updated 04-Jun-2006 07:24:29 UTC\r
 </div>\r
 </div>\r
 </body>\r