X-Git-Url: https://git.octo.it/?a=blobdiff_plain;f=Documentation%2Fgit-read-tree.txt;h=d894f537ba2634ed2719ee746b170a22f0173f56;hb=2662dbfa58a2d12d1ab3d240b643b9506f43523b;hp=6fbd6d9368a4bd33167c22373614d06463fa2a2e;hpb=8c667f4bb878a7bcb45eb6dbd920b8aba9718d7e;p=git.git

diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 6fbd6d93..d894f537 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -8,7 +8,7 @@ git-read-tree - Reads tree information into the index
 
 SYNOPSIS
 --------
-'git-read-tree' (<tree-ish> | [[-m | --reset] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+'git-read-tree' (<tree-ish> | [[-m [--aggressive]| --reset] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
 
 
 DESCRIPTION
@@ -50,6 +50,19 @@ OPTIONS
 	trees that are not directly related to the current
 	working tree status into a temporary index file.
 
+--aggressive::
+	Usually a three-way merge by `git-read-tree` resolves
+	the merge for really trivial cases and leaves other
+	cases unresolved in the index, so that Porcelains can
+	implement different merge policies.  This flag makes the
+	command to resolve a few more cases internally:
++
+* when one side removes a path and the other side leaves the path
+  unmodified.  The resolution is to remove that path.
+* when both sides remove a path.  The resolution is to remove that path.
+* when both sides adds a path identically.  The resolution
+  is to add that path.
+
 <tree-ish#>::
 	The id of the tree object(s) to be read/merged.
 
@@ -192,7 +205,7 @@ The `git-write-tree` command refuses to write a nonsensical tree, and it
 will complain about unmerged entries if it sees a single entry that is not
 stage 0.
 
-Ok, this all sounds like a collection of totally nonsensical rules,
+OK, this all sounds like a collection of totally nonsensical rules,
 but it's actually exactly what you want in order to do a fast
 merge. The different stages represent the "result tree" (stage 0, aka
 "merged"), the original tree (stage 1, aka "orig"), and the two trees
@@ -213,7 +226,7 @@ populated.  Here is an outline of how the algorithm works:
 
 - the index file saves and restores with all this information, so you
   can merge things incrementally, but as long as it has entries in
-  stages 1/2/3 (ie "unmerged entries") you can't write the result. So
+  stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So
   now the merge algorithm ends up being really simple:
 
   * you walk the index in order, and ignore all entries of stage 0,
@@ -244,7 +257,7 @@ file that does not match stage 2.
 This is done to prevent you from losing your work-in-progress
 changes, and mixing your random changes in an unrelated merge
 commit.  To illustrate, suppose you start from what has been
-commited last to your repository:
+committed last to your repository:
 
 ----------------
 $ JC=`git-rev-parse --verify "HEAD^0"`