<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
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-read-tree</em> (<tree-ish> | [[-m | --reset] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])</p>\r
+<p><em>git-read-tree</em> (<tree-ish> | [[-m [--aggressive]| --reset] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</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
<tree-ish#>\r
</dt>\r
<dd>\r
<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
<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
</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