| Junio C Hamano | 1a4e841 | 2005-12-27 08:17:23 | [diff] [blame] | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" |
| 2 | "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> |
| 3 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> |
| 4 | <head> |
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> |
| Junio C Hamano | 5f32776 | 2006-03-02 09:14:51 | [diff] [blame] | 6 | <meta name="generator" content="AsciiDoc 7.0.2" /> |
| Junio C Hamano | 1a4e841 | 2005-12-27 08:17:23 | [diff] [blame] | 7 | <style type="text/css"> |
| 8 | /* Debug borders */ |
| 9 | p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 { |
| 10 | /* |
| 11 | border: 1px solid red; |
| 12 | */ |
| 13 | } |
| 14 | |
| 15 | body { |
| 16 | margin: 1em 5% 1em 5%; |
| 17 | } |
| 18 | |
| 19 | a { color: blue; } |
| 20 | a:visited { color: fuchsia; } |
| 21 | |
| 22 | em { |
| 23 | font-style: italic; |
| 24 | } |
| 25 | |
| 26 | strong { |
| 27 | font-weight: bold; |
| 28 | } |
| 29 | |
| 30 | tt { |
| 31 | color: navy; |
| 32 | } |
| 33 | |
| 34 | h1, h2, h3, h4, h5, h6 { |
| 35 | color: #527bbd; |
| 36 | font-family: sans-serif; |
| 37 | margin-top: 1.2em; |
| 38 | margin-bottom: 0.5em; |
| 39 | line-height: 1.3; |
| 40 | } |
| 41 | |
| 42 | h1 { |
| 43 | border-bottom: 2px solid silver; |
| 44 | } |
| 45 | h2 { |
| 46 | border-bottom: 2px solid silver; |
| 47 | padding-top: 0.5em; |
| 48 | } |
| 49 | |
| 50 | div.sectionbody { |
| 51 | font-family: serif; |
| 52 | margin-left: 0; |
| 53 | } |
| 54 | |
| 55 | hr { |
| 56 | border: 1px solid silver; |
| 57 | } |
| 58 | |
| 59 | p { |
| 60 | margin-top: 0.5em; |
| 61 | margin-bottom: 0.5em; |
| 62 | } |
| 63 | |
| 64 | pre { |
| 65 | padding: 0; |
| 66 | margin: 0; |
| 67 | } |
| 68 | |
| 69 | span#author { |
| 70 | color: #527bbd; |
| 71 | font-family: sans-serif; |
| 72 | font-weight: bold; |
| 73 | font-size: 1.2em; |
| 74 | } |
| 75 | span#email { |
| 76 | } |
| 77 | span#revision { |
| 78 | font-family: sans-serif; |
| 79 | } |
| 80 | |
| 81 | div#footer { |
| 82 | font-family: sans-serif; |
| 83 | font-size: small; |
| 84 | border-top: 2px solid silver; |
| 85 | padding-top: 0.5em; |
| 86 | margin-top: 4.0em; |
| 87 | } |
| 88 | div#footer-text { |
| 89 | float: left; |
| 90 | padding-bottom: 0.5em; |
| 91 | } |
| 92 | div#footer-badges { |
| 93 | float: right; |
| 94 | padding-bottom: 0.5em; |
| 95 | } |
| 96 | |
| 97 | div#preamble, |
| 98 | div.tableblock, div.imageblock, div.exampleblock, div.verseblock, |
| 99 | div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock, |
| 100 | div.admonitionblock { |
| 101 | margin-right: 10%; |
| 102 | margin-top: 1.5em; |
| 103 | margin-bottom: 1.5em; |
| 104 | } |
| 105 | div.admonitionblock { |
| 106 | margin-top: 2.5em; |
| 107 | margin-bottom: 2.5em; |
| 108 | } |
| 109 | |
| 110 | div.content { /* Block element content. */ |
| 111 | padding: 0; |
| 112 | } |
| 113 | |
| 114 | /* Block element titles. */ |
| 115 | div.title, caption.title { |
| 116 | font-family: sans-serif; |
| 117 | font-weight: bold; |
| 118 | text-align: left; |
| 119 | margin-top: 1.0em; |
| 120 | margin-bottom: 0.5em; |
| 121 | } |
| 122 | div.title + * { |
| 123 | margin-top: 0; |
| 124 | } |
| 125 | |
| 126 | td div.title:first-child { |
| 127 | margin-top: 0.0em; |
| 128 | } |
| 129 | div.content div.title:first-child { |
| 130 | margin-top: 0.0em; |
| 131 | } |
| 132 | div.content + div.title { |
| 133 | margin-top: 0.0em; |
| 134 | } |
| 135 | |
| 136 | div.sidebarblock > div.content { |
| 137 | background: #ffffee; |
| 138 | border: 1px solid silver; |
| 139 | padding: 0.5em; |
| 140 | } |
| 141 | |
| 142 | div.listingblock > div.content { |
| 143 | border: 1px solid silver; |
| 144 | background: #f4f4f4; |
| 145 | padding: 0.5em; |
| 146 | } |
| 147 | |
| 148 | div.quoteblock > div.content { |
| 149 | padding-left: 2.0em; |
| 150 | } |
| 151 | div.quoteblock .attribution { |
| 152 | text-align: right; |
| 153 | } |
| 154 | |
| 155 | div.admonitionblock .icon { |
| 156 | vertical-align: top; |
| 157 | font-size: 1.1em; |
| 158 | font-weight: bold; |
| 159 | text-decoration: underline; |
| 160 | color: #527bbd; |
| 161 | padding-right: 0.5em; |
| 162 | } |
| 163 | div.admonitionblock td.content { |
| 164 | padding-left: 0.5em; |
| 165 | border-left: 2px solid silver; |
| 166 | } |
| 167 | |
| 168 | div.exampleblock > div.content { |
| 169 | border-left: 2px solid silver; |
| 170 | padding: 0.5em; |
| 171 | } |
| 172 | |
| 173 | div.verseblock div.content { |
| 174 | white-space: pre; |
| 175 | } |
| 176 | |
| 177 | div.imageblock div.content { padding-left: 0; } |
| 178 | div.imageblock img { border: 1px solid silver; } |
| 179 | span.image img { border-style: none; } |
| 180 | |
| 181 | dl { |
| 182 | margin-top: 0.8em; |
| 183 | margin-bottom: 0.8em; |
| 184 | } |
| 185 | dt { |
| 186 | margin-top: 0.5em; |
| 187 | margin-bottom: 0; |
| 188 | font-style: italic; |
| 189 | } |
| 190 | dd > *:first-child { |
| 191 | margin-top: 0; |
| 192 | } |
| 193 | |
| 194 | ul, ol { |
| 195 | list-style-position: outside; |
| 196 | } |
| 197 | ol.olist2 { |
| 198 | list-style-type: lower-alpha; |
| 199 | } |
| 200 | |
| 201 | div.tableblock > table { |
| 202 | border-color: #527bbd; |
| 203 | border-width: 3px; |
| 204 | } |
| 205 | thead { |
| 206 | font-family: sans-serif; |
| 207 | font-weight: bold; |
| 208 | } |
| 209 | tfoot { |
| 210 | font-weight: bold; |
| 211 | } |
| 212 | |
| 213 | div.hlist { |
| 214 | margin-top: 0.8em; |
| 215 | margin-bottom: 0.8em; |
| 216 | } |
| 217 | td.hlist1 { |
| 218 | vertical-align: top; |
| 219 | font-style: italic; |
| 220 | padding-right: 0.8em; |
| 221 | } |
| 222 | td.hlist2 { |
| 223 | vertical-align: top; |
| 224 | } |
| 225 | |
| 226 | @media print { |
| 227 | div#footer-badges { display: none; } |
| 228 | } |
| 229 | include::./stylesheets/xhtml11-manpage.css[] |
| 230 | /* Workarounds for IE6's broken and incomplete CSS2. */ |
| 231 | |
| 232 | div.sidebar-content { |
| 233 | background: #ffffee; |
| 234 | border: 1px solid silver; |
| 235 | padding: 0.5em; |
| 236 | } |
| 237 | div.sidebar-title, div.image-title { |
| 238 | font-family: sans-serif; |
| 239 | font-weight: bold; |
| 240 | margin-top: 0.0em; |
| 241 | margin-bottom: 0.5em; |
| 242 | } |
| 243 | |
| 244 | div.listingblock div.content { |
| 245 | border: 1px solid silver; |
| 246 | background: #f4f4f4; |
| 247 | padding: 0.5em; |
| 248 | } |
| 249 | |
| 250 | div.quoteblock-content { |
| 251 | padding-left: 2.0em; |
| 252 | } |
| 253 | |
| 254 | div.exampleblock-content { |
| 255 | border-left: 2px solid silver; |
| 256 | padding-left: 0.5em; |
| 257 | } |
| 258 | </style> |
| 259 | <title>git-read-tree(1)</title> |
| 260 | </head> |
| 261 | <body> |
| 262 | <div id="header"> |
| 263 | <h1> |
| 264 | git-read-tree(1) Manual Page |
| 265 | </h1> |
| 266 | <h2>NAME</h2> |
| 267 | <div class="sectionbody"> |
| 268 | <p>git-read-tree - |
| 269 | Reads tree information into the index |
| 270 | </p> |
| 271 | </div> |
| 272 | </div> |
| 273 | <h2>SYNOPSIS</h2> |
| 274 | <div class="sectionbody"> |
| Junio C Hamano | 5f32776 | 2006-03-02 09:14:51 | [diff] [blame] | 275 | <p><em>git-read-tree</em> (<tree-ish> | [[-m [--aggressive]| --reset] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])</p> |
| Junio C Hamano | 1a4e841 | 2005-12-27 08:17:23 | [diff] [blame] | 276 | </div> |
| 277 | <h2>DESCRIPTION</h2> |
| 278 | <div class="sectionbody"> |
| 279 | <p>Reads the tree information given by <tree-ish> into the index, |
| 280 | but does not actually <strong>update</strong> any of the files it "caches". (see: |
| 281 | <a href="git-checkout-index.html">git-checkout-index(1)</a>)</p> |
| 282 | <p>Optionally, it can merge a tree into the index, perform a |
| 283 | fast-forward (i.e. 2-way) merge, or a 3-way merge, with the <tt>-m</tt> |
| 284 | flag. When used with <tt>-m</tt>, the <tt>-u</tt> flag causes it to also update |
| 285 | the files in the work tree with the result of the merge.</p> |
| 286 | <p>Trivial merges are done by <tt>git-read-tree</tt> itself. Only conflicting paths |
| 287 | will be in unmerged state when <tt>git-read-tree</tt> returns.</p> |
| 288 | </div> |
| 289 | <h2>OPTIONS</h2> |
| 290 | <div class="sectionbody"> |
| 291 | <dl> |
| 292 | <dt> |
| 293 | -m |
| 294 | </dt> |
| 295 | <dd> |
| 296 | <p> |
| 297 | Perform a merge, not just a read. The command will |
| 298 | refuse to run if your index file has unmerged entries, |
| 299 | indicating that you have not finished previous merge you |
| 300 | started. |
| 301 | </p> |
| 302 | </dd> |
| 303 | <dt> |
| 304 | --reset |
| 305 | </dt> |
| 306 | <dd> |
| 307 | <p> |
| 308 | Same as -m, except that unmerged entries are discarded |
| 309 | instead of failing. |
| 310 | </p> |
| 311 | </dd> |
| 312 | <dt> |
| 313 | -u |
| 314 | </dt> |
| 315 | <dd> |
| 316 | <p> |
| 317 | After a successful merge, update the files in the work |
| 318 | tree with the result of the merge. |
| 319 | </p> |
| 320 | </dd> |
| 321 | <dt> |
| 322 | -i |
| 323 | </dt> |
| 324 | <dd> |
| 325 | <p> |
| 326 | Usually a merge requires the index file as well as the |
| 327 | files in the working tree are up to date with the |
| 328 | current head commit, in order not to lose local |
| 329 | changes. This flag disables the check with the working |
| 330 | tree and is meant to be used when creating a merge of |
| 331 | trees that are not directly related to the current |
| 332 | working tree status into a temporary index file. |
| 333 | </p> |
| 334 | </dd> |
| 335 | <dt> |
| Junio C Hamano | 5f32776 | 2006-03-02 09:14:51 | [diff] [blame] | 336 | --aggressive |
| 337 | </dt> |
| 338 | <dd> |
| 339 | <p> |
| 340 | Usually a three-way merge by <tt>git-read-tree</tt> resolves |
| 341 | the merge for really trivial cases and leaves other |
| 342 | cases unresolved in the index, so that Porcelains can |
| 343 | implement different merge policies. This flag makes the |
| 344 | command to resolve a few more cases internally: |
| 345 | </p> |
| 346 | <ul> |
| 347 | <li> |
| 348 | <p> |
| 349 | when one side removes a path and the other side leaves the path |
| 350 | unmodified. The resolution is to remove that path. |
| 351 | </p> |
| 352 | </li> |
| 353 | <li> |
| 354 | <p> |
| 355 | when both sides remove a path. The resolution is to remove that path. |
| 356 | </p> |
| 357 | </li> |
| 358 | <li> |
| 359 | <p> |
| 360 | when both sides adds a path identically. The resolution |
| 361 | is to add that path. |
| 362 | </p> |
| 363 | </li> |
| 364 | </ul> |
| 365 | </dd> |
| 366 | <dt> |
| Junio C Hamano | 1a4e841 | 2005-12-27 08:17:23 | [diff] [blame] | 367 | <tree-ish#> |
| 368 | </dt> |
| 369 | <dd> |
| 370 | <p> |
| 371 | The id of the tree object(s) to be read/merged. |
| 372 | </p> |
| 373 | </dd> |
| 374 | </dl> |
| 375 | </div> |
| 376 | <h2>Merging</h2> |
| 377 | <div class="sectionbody"> |
| 378 | <p>If <tt>-m</tt> is specified, <tt>git-read-tree</tt> can perform 3 kinds of |
| 379 | merge, a single tree merge if only 1 tree is given, a |
| 380 | fast-forward merge with 2 trees, or a 3-way merge if 3 trees are |
| 381 | provided.</p> |
| 382 | <h3>Single Tree Merge</h3> |
| 383 | <p>If only 1 tree is specified, git-read-tree operates as if the user did not |
| 384 | specify <tt>-m</tt>, except that if the original index has an entry for a |
| 385 | given pathname, and the contents of the path matches with the tree |
| 386 | being read, the stat info from the index is used. (In other words, the |
| 387 | index's stat()s take precedence over the merged tree's).</p> |
| 388 | <p>That means that if you do a <tt>git-read-tree -m <newtree></tt> followed by a |
| 389 | <tt>git-checkout-index -f -u -a</tt>, the <tt>git-checkout-index</tt> only checks out |
| 390 | the stuff that really changed.</p> |
| 391 | <p>This is used to avoid unnecessary false hits when <tt>git-diff-files</tt> is |
| 392 | run after <tt>git-read-tree</tt>.</p> |
| 393 | <h3>Two Tree Merge</h3> |
| 394 | <p>Typically, this is invoked as <tt>git-read-tree -m $H $M</tt>, where $H |
| 395 | is the head commit of the current repository, and $M is the head |
| 396 | of a foreign tree, which is simply ahead of $H (i.e. we are in a |
| 397 | fast forward situation).</p> |
| 398 | <p>When two trees are specified, the user is telling git-read-tree |
| 399 | the following:</p> |
| 400 | <ol> |
| 401 | <li> |
| 402 | <p> |
| 403 | The current index and work tree is derived from $H, but |
| 404 | the user may have local changes in them since $H; |
| 405 | </p> |
| 406 | </li> |
| 407 | <li> |
| 408 | <p> |
| 409 | The user wants to fast-forward to $M. |
| 410 | </p> |
| 411 | </li> |
| 412 | </ol> |
| 413 | <p>In this case, the <tt>git-read-tree -m $H $M</tt> command makes sure |
| 414 | that no local change is lost as the result of this "merge". |
| 415 | Here are the "carry forward" rules:</p> |
| 416 | <div class="literalblock"> |
| 417 | <div class="content"> |
| 418 | <pre><tt> I (index) H M Result |
| 419 | ------------------------------------------------------- |
| 420 | 0 nothing nothing nothing (does not happen) |
| 421 | 1 nothing nothing exists use M |
| 422 | 2 nothing exists nothing remove path from index |
| 423 | 3 nothing exists exists use M</tt></pre> |
| 424 | </div></div> |
| 425 | <div class="literalblock"> |
| 426 | <div class="content"> |
| 427 | <pre><tt> clean I==H I==M |
| 428 | ------------------ |
| 429 | 4 yes N/A N/A nothing nothing keep index |
| 430 | 5 no N/A N/A nothing nothing keep index</tt></pre> |
| 431 | </div></div> |
| 432 | <div class="literalblock"> |
| 433 | <div class="content"> |
| 434 | <pre><tt>6 yes N/A yes nothing exists keep index |
| 435 | 7 no N/A yes nothing exists keep index |
| 436 | 8 yes N/A no nothing exists fail |
| 437 | 9 no N/A no nothing exists fail</tt></pre> |
| 438 | </div></div> |
| 439 | <div class="literalblock"> |
| 440 | <div class="content"> |
| 441 | <pre><tt>10 yes yes N/A exists nothing remove path from index |
| 442 | 11 no yes N/A exists nothing fail |
| 443 | 12 yes no N/A exists nothing fail |
| 444 | 13 no no N/A exists nothing fail</tt></pre> |
| 445 | </div></div> |
| 446 | <div class="literalblock"> |
| 447 | <div class="content"> |
| 448 | <pre><tt> clean (H=M) |
| 449 | ------ |
| 450 | 14 yes exists exists keep index |
| 451 | 15 no exists exists keep index</tt></pre> |
| 452 | </div></div> |
| 453 | <div class="literalblock"> |
| 454 | <div class="content"> |
| 455 | <pre><tt> clean I==H I==M (H!=M) |
| 456 | ------------------ |
| 457 | 16 yes no no exists exists fail |
| 458 | 17 no no no exists exists fail |
| 459 | 18 yes no yes exists exists keep index |
| 460 | 19 no no yes exists exists keep index |
| 461 | 20 yes yes no exists exists use M |
| 462 | 21 no yes no exists exists fail</tt></pre> |
| 463 | </div></div> |
| 464 | <p>In all "keep index" cases, the index entry stays as in the |
| 465 | original index file. If the entry were not up to date, |
| 466 | git-read-tree keeps the copy in the work tree intact when |
| 467 | operating under the -u flag.</p> |
| 468 | <p>When this form of git-read-tree returns successfully, you can |
| 469 | see what "local changes" you made are carried forward by running |
| 470 | <tt>git-diff-index --cached $M</tt>. Note that this does not |
| 471 | necessarily match <tt>git-diff-index --cached $H</tt> would have |
| 472 | produced before such a two tree merge. This is because of cases |
| 473 | 18 and 19 --- if you already had the changes in $M (e.g. maybe |
| 474 | you picked it up via e-mail in a patch form), <tt>git-diff-index |
| 475 | --cached $H</tt> would have told you about the change before this |
| 476 | merge, but it would not show in <tt>git-diff-index --cached $M</tt> |
| 477 | output after two-tree merge.</p> |
| 478 | <h3>3-Way Merge</h3> |
| 479 | <p>Each "index" entry has two bits worth of "stage" state. stage 0 is the |
| 480 | normal one, and is the only one you'd see in any kind of normal use.</p> |
| 481 | <p>However, when you do <tt>git-read-tree</tt> with three trees, the "stage" |
| 482 | starts out at 1.</p> |
| 483 | <p>This means that you can do</p> |
| 484 | <div class="listingblock"> |
| 485 | <div class="content"> |
| 486 | <pre><tt>$ git-read-tree -m <tree1> <tree2> <tree3></tt></pre> |
| 487 | </div></div> |
| 488 | <p>and you will end up with an index with all of the <tree1> entries in |
| 489 | "stage1", all of the <tree2> entries in "stage2" and all of the |
| 490 | <tree3> entries in "stage3". When performing a merge of another |
| 491 | branch into the current branch, we use the common ancestor tree |
| 492 | as <tree1>, the current branch head as <tree2>, and the other |
| 493 | branch head as <tree3>.</p> |
| 494 | <p>Furthermore, <tt>git-read-tree</tt> has special-case logic that says: if you see |
| 495 | a file that matches in all respects in the following states, it |
| 496 | "collapses" back to "stage0":</p> |
| 497 | <ul> |
| 498 | <li> |
| 499 | <p> |
| 500 | stage 2 and 3 are the same; take one or the other (it makes no |
| 501 | difference - the same work has been done on our branch in |
| 502 | stage 2 and their branch in stage 3) |
| 503 | </p> |
| 504 | </li> |
| 505 | <li> |
| 506 | <p> |
| 507 | stage 1 and stage 2 are the same and stage 3 is different; take |
| 508 | stage 3 (our branch in stage 2 did not do anything since the |
| 509 | ancestor in stage 1 while their branch in stage 3 worked on |
| 510 | it) |
| 511 | </p> |
| 512 | </li> |
| 513 | <li> |
| 514 | <p> |
| 515 | stage 1 and stage 3 are the same and stage 2 is different take |
| 516 | stage 2 (we did something while they did nothing) |
| 517 | </p> |
| 518 | </li> |
| 519 | </ul> |
| 520 | <p>The <tt>git-write-tree</tt> command refuses to write a nonsensical tree, and it |
| 521 | will complain about unmerged entries if it sees a single entry that is not |
| 522 | stage 0.</p> |
| 523 | <p>Ok, this all sounds like a collection of totally nonsensical rules, |
| 524 | but it's actually exactly what you want in order to do a fast |
| 525 | merge. The different stages represent the "result tree" (stage 0, aka |
| 526 | "merged"), the original tree (stage 1, aka "orig"), and the two trees |
| 527 | you are trying to merge (stage 2 and 3 respectively).</p> |
| 528 | <p>The order of stages 1, 2 and 3 (hence the order of three |
| 529 | <tree-ish> command line arguments) are significant when you |
| 530 | start a 3-way merge with an index file that is already |
| 531 | populated. Here is an outline of how the algorithm works:</p> |
| 532 | <ul> |
| 533 | <li> |
| 534 | <p> |
| 535 | if a file exists in identical format in all three trees, it will |
| 536 | automatically collapse to "merged" state by git-read-tree. |
| 537 | </p> |
| 538 | </li> |
| 539 | <li> |
| 540 | <p> |
| 541 | a file that has _any_ difference what-so-ever in the three trees |
| 542 | will stay as separate entries in the index. It's up to "porcelain |
| 543 | policy" to determine how to remove the non-0 stages, and insert a |
| 544 | merged version. |
| 545 | </p> |
| 546 | </li> |
| 547 | <li> |
| 548 | <p> |
| 549 | the index file saves and restores with all this information, so you |
| 550 | can merge things incrementally, but as long as it has entries in |
| 551 | stages 1/2/3 (ie "unmerged entries") you can't write the result. So |
| 552 | now the merge algorithm ends up being really simple: |
| 553 | </p> |
| 554 | <ul> |
| 555 | <li> |
| 556 | <p> |
| 557 | you walk the index in order, and ignore all entries of stage 0, |
| 558 | since they've already been done. |
| 559 | </p> |
| 560 | </li> |
| 561 | <li> |
| 562 | <p> |
| 563 | if you find a "stage1", but no matching "stage2" or "stage3", you |
| 564 | know it's been removed from both trees (it only existed in the |
| 565 | original tree), and you remove that entry. |
| 566 | </p> |
| 567 | </li> |
| 568 | <li> |
| 569 | <p> |
| 570 | if you find a matching "stage2" and "stage3" tree, you remove one |
| 571 | of them, and turn the other into a "stage0" entry. Remove any |
| 572 | matching "stage1" entry if it exists too. .. all the normal |
| 573 | trivial rules .. |
| 574 | </p> |
| 575 | </li> |
| 576 | </ul> |
| 577 | </li> |
| 578 | </ul> |
| 579 | <p>You would normally use <tt>git-merge-index</tt> with supplied |
| 580 | <tt>git-merge-one-file</tt> to do this last step. The script updates |
| 581 | the files in the working tree as it merges each path and at the |
| 582 | end of a successful merge.</p> |
| 583 | <p>When you start a 3-way merge with an index file that is already |
| 584 | populated, it is assumed that it represents the state of the |
| 585 | files in your work tree, and you can even have files with |
| 586 | changes unrecorded in the index file. It is further assumed |
| 587 | that this state is "derived" from the stage 2 tree. The 3-way |
| 588 | merge refuses to run if it finds an entry in the original index |
| 589 | file that does not match stage 2.</p> |
| 590 | <p>This is done to prevent you from losing your work-in-progress |
| 591 | changes, and mixing your random changes in an unrelated merge |
| 592 | commit. To illustrate, suppose you start from what has been |
| 593 | commited last to your repository:</p> |
| 594 | <div class="listingblock"> |
| 595 | <div class="content"> |
| 596 | <pre><tt>$ JC=`git-rev-parse --verify "HEAD^0"` |
| 597 | $ git-checkout-index -f -u -a $JC</tt></pre> |
| 598 | </div></div> |
| 599 | <p>You do random edits, without running git-update-index. And then |
| 600 | you notice that the tip of your "upstream" tree has advanced |
| 601 | since you pulled from him:</p> |
| 602 | <div class="listingblock"> |
| 603 | <div class="content"> |
| 604 | <pre><tt>$ git-fetch git://.... linus |
| 605 | $ LT=`cat .git/FETCH_HEAD`</tt></pre> |
| 606 | </div></div> |
| 607 | <p>Your work tree is still based on your HEAD ($JC), but you have |
| 608 | some edits since. Three-way merge makes sure that you have not |
| 609 | added or modified index entries since $JC, and if you haven't, |
| 610 | then does the right thing. So with the following sequence:</p> |
| 611 | <div class="listingblock"> |
| 612 | <div class="content"> |
| 613 | <pre><tt>$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT |
| 614 | $ git-merge-index git-merge-one-file -a |
| 615 | $ echo "Merge with Linus" | \ |
| 616 | git-commit-tree `git-write-tree` -p $JC -p $LT</tt></pre> |
| 617 | </div></div> |
| 618 | <p>what you would commit is a pure merge between $JC and $LT without |
| 619 | your work-in-progress changes, and your work tree would be |
| 620 | updated to the result of the merge.</p> |
| 621 | <p>However, if you have local changes in the working tree that |
| 622 | would be overwritten by this merge,<tt>git-read-tree</tt> will refuse |
| 623 | to run to prevent your changes from being lost.</p> |
| 624 | <p>In other words, there is no need to worry about what exists only |
| 625 | in the working tree. When you have local changes in a part of |
| 626 | the project that is not involved in the merge, your changes do |
| 627 | not interfere with the merge, and are kept intact. When they |
| 628 | <strong>do</strong> interfere, the merge does not even start (<tt>git-read-tree</tt> |
| 629 | complains loudly and fails without modifying anything). In such |
| 630 | a case, you can simply continue doing what you were in the |
| 631 | middle of doing, and when your working tree is ready (i.e. you |
| 632 | have finished your work-in-progress), attempt the merge again.</p> |
| 633 | </div> |
| 634 | <h2>See Also</h2> |
| 635 | <div class="sectionbody"> |
| 636 | <p><a href="git-write-tree.html">git-write-tree(1)</a>; <a href="git-ls-files.html">git-ls-files(1)</a></p> |
| 637 | </div> |
| 638 | <h2>Author</h2> |
| 639 | <div class="sectionbody"> |
| 640 | <p>Written by Linus Torvalds <torvalds@osdl.org></p> |
| 641 | </div> |
| 642 | <h2>Documentation</h2> |
| 643 | <div class="sectionbody"> |
| 644 | <p>Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.</p> |
| 645 | </div> |
| 646 | <h2>GIT</h2> |
| 647 | <div class="sectionbody"> |
| 648 | <p>Part of the <a href="git.html">git(7)</a> suite</p> |
| 649 | </div> |
| 650 | <div id="footer"> |
| 651 | <div id="footer-text"> |
| Junio C Hamano | 5f32776 | 2006-03-02 09:14:51 | [diff] [blame] | 652 | Last updated 02-Mar-2006 09:14:48 UTC |
| Junio C Hamano | 1a4e841 | 2005-12-27 08:17:23 | [diff] [blame] | 653 | </div> |
| 654 | </div> |
| 655 | </body> |
| 656 | </html> |
