Autogenerated HTML docs for v1.6.0.2-249-g97d7f
authorJunio C Hamano <junio@hera.kernel.org>
Tue, 16 Sep 2008 19:17:31 +0000 (19:17 +0000)
committerJunio C Hamano <junio@hera.kernel.org>
Tue, 16 Sep 2008 19:17:31 +0000 (19:17 +0000)
git-read-tree.html
git-read-tree.txt

index 31d8eed0251550316ff5948192865d1307f56901..5582b864fdc7555af418d19adb6d506beb0094ee 100644 (file)
@@ -537,7 +537,10 @@ Here are the "carry forward" rules:</p></div>
 0 nothing             nothing  nothing  (does not happen)\r
 1 nothing             nothing  exists   use M\r
 2 nothing             exists   nothing  remove path from index\r
-3 nothing             exists   exists   use M</tt></pre>\r
+3 nothing             exists   exists,  use M if "initial checkout"\r
+                               H == M   keep index otherwise\r
+                               exists   fail\r
+                               H != M</tt></pre>\r
 </div></div>\r
 <div class="literalblock">\r
 <div class="content">\r
@@ -592,6 +595,12 @@ you picked it up via e-mail in a patch form), <tt>git diff-index
 --cached $H</tt> would have told you about the change before this\r
 merge, but it would not show in <tt>git diff-index --cached $M</tt>\r
 output after two-tree merge.</p></div>\r
+<div class="para"><p>Case #3 is slightly tricky and needs explanation.  The result from this\r
+rule logically should be to remove the path if the user staged the removal\r
+of the path and then swiching to a new branch.  That however will prevent\r
+the initial checkout from happening, so the rule is modified to use M (new\r
+tree) only when the contents of the index is empty.  Otherwise the removal\r
+of the path is kept as long as $H and $M are the same.</p></div>\r
 <h3 id="_3_way_merge">3-Way Merge</h3><div style="clear:left"></div>\r
 <div class="para"><p>Each "index" entry has two bits worth of "stage" state. stage 0 is the\r
 normal one, and is the only one you'd see in any kind of normal use.</p></div>\r
@@ -767,7 +776,7 @@ have finished your work-in-progress), attempt the merge again.</p></div>
 </div>\r
 <div id="footer">\r
 <div id="footer-text">\r
-Last updated 2008-07-06 05:16:57 UTC\r
+Last updated 2008-09-16 19:17:16 UTC\r
 </div>\r
 </div>\r
 </body>\r
index 6f4b9b017f7b504a2b9e909639a61b1ef7750af0..309deac23b5bf8eea28441d34e78b7cdb3a02d28 100644 (file)
@@ -160,7 +160,10 @@ Here are the "carry forward" rules:
       0 nothing             nothing  nothing  (does not happen)
       1 nothing             nothing  exists   use M
       2 nothing             exists   nothing  remove path from index
-      3 nothing             exists   exists   use M
+      3 nothing             exists   exists,  use M if "initial checkout"
+                                    H == M   keep index otherwise
+                                    exists   fail
+                                    H != M
 
         clean I==H  I==M
        ------------------
@@ -207,6 +210,12 @@ you picked it up via e-mail in a patch form), `git diff-index
 merge, but it would not show in `git diff-index --cached $M`
 output after two-tree merge.
 
+Case #3 is slightly tricky and needs explanation.  The result from this
+rule logically should be to remove the path if the user staged the removal
+of the path and then swiching to a new branch.  That however will prevent
+the initial checkout from happening, so the rule is modified to use M (new
+tree) only when the contents of the index is empty.  Otherwise the removal
+of the path is kept as long as $H and $M are the same.
 
 3-Way Merge
 ~~~~~~~~~~~