| blob | dab6836f89464e892599a0dff7e0533c897aa41a |
4 <head>
9 /* Debug borders */
11 /*
12 border: 1px solid red;
13 */
14 }
16 body {
18 }
20 a {
23 }
26 }
28 em {
31 }
33 strong {
36 }
38 tt {
40 }
48 }
52 }
53 h2 {
55 }
56 h3 {
58 }
59 h3 + * {
61 }
66 }
68 hr {
70 }
72 p {
75 }
79 }
81 pre {
84 }
86 span#author {
91 }
92 span#email {
93 }
96 }
98 div#footer {
104 }
105 div#footer-text {
108 }
109 div#footer-badges {
112 }
114 div#preamble {
117 }
123 }
127 }
131 }
133 /* Block element titles. */
141 }
144 }
148 }
151 }
154 }
160 }
166 }
171 }
175 }
180 }
183 }
187 }
188 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
191 }
200 }
204 }
209 }
215 dl {
218 }
219 dt {
224 }
227 }
231 }
234 }
237 }
240 }
243 }
246 }
253 }
257 }
258 thead {
261 }
262 tfoot {
264 }
267 }
270 }
271 /* Because the table frame attribute is overriden by CSS in most browsers. */
274 }
278 }
282 }
288 }
291 }
294 }
300 }
303 }
307 }
311 }
315 }
317 div#toctitle {
324 }
329 }
333 }
337 }
341 }
342 /* Overrides for manpage documents */
343 h1 {
348 }
349 h2 {
351 }
354 }
358 }
360 /* Workarounds for IE6's broken and incomplete CSS2. */
366 }
373 }
379 }
384 }
388 }
392 }
397 }
399 /* IE6 sets dynamically generated links as visited. */
401 </style>
402 </head>
403 <body>
405 <h1>
406 git-read-tree(1) Manual Page
407 </h1>
410 <p>git-read-tree -
411 Reads tree information into the index
412 </p>
413 </div>
414 </div>
417 <div class="paragraph"><p><em>git read-tree</em> [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>]
421 </div>
430 the files in the work tree with the result of the merge.</p></div>
431 <div class="paragraph"><p>Trivial merges are done by <em>git read-tree</em> itself. Only conflicting paths
433 </div>
438 -m
439 </dt>
440 <dd>
441 <p>
442 Perform a merge, not just a read. The command will
443 refuse to run if your index file has unmerged entries,
444 indicating that you have not finished previous merge you
445 started.
446 </p>
447 </dd>
449 --reset
450 </dt>
451 <dd>
452 <p>
453 Same as -m, except that unmerged entries are discarded
454 instead of failing.
455 </p>
456 </dd>
458 -u
459 </dt>
460 <dd>
461 <p>
462 After a successful merge, update the files in the work
463 tree with the result of the merge.
464 </p>
465 </dd>
467 -i
468 </dt>
469 <dd>
470 <p>
471 Usually a merge requires the index file as well as the
472 files in the working tree are up to date with the
473 current head commit, in order not to lose local
474 changes. This flag disables the check with the working
475 tree and is meant to be used when creating a merge of
476 trees that are not directly related to the current
477 working tree status into a temporary index file.
478 </p>
479 </dd>
481 -v
482 </dt>
483 <dd>
484 <p>
485 Show the progress of checking files out.
486 </p>
487 </dd>
489 --trivial
490 </dt>
491 <dd>
492 <p>
494 only if there is no file-level merging required, instead
495 of resolving merge for trivial cases and leaving
496 conflicting files unresolved in the index.
497 </p>
498 </dd>
500 --aggressive
501 </dt>
502 <dd>
503 <p>
505 the merge for really trivial cases and leaves other
506 cases unresolved in the index, so that Porcelains can
507 implement different merge policies. This flag makes the
508 command to resolve a few more cases internally:
509 </p>
511 <li>
512 <p>
513 when one side removes a path and the other side leaves the path
514 unmodified. The resolution is to remove that path.
515 </p>
516 </li>
517 <li>
518 <p>
519 when both sides remove a path. The resolution is to remove that path.
520 </p>
521 </li>
522 <li>
523 <p>
524 when both sides adds a path identically. The resolution
525 is to add that path.
526 </p>
527 </li>
528 </ul></div>
529 </dd>
532 </dt>
533 <dd>
534 <p>
535 Keep the current index contents, and read the contents
537 original index file cannot have anything at the path
540 with a slash.
541 </p>
542 </dd>
545 </dt>
546 <dd>
547 <p>
549 merge result may need to overwrite paths that are not
550 tracked in the current branch. The command usually
551 refuses to proceed with the merge to avoid losing such a
552 path. However this safety valve sometimes gets in the
553 way. For example, it often happens that the other
554 branch added a file that used to be a generated file in
555 your branch, and the safety valve triggers when you try
558 option tells the command to read per-directory exclude
560 but explicitly ignored file to be overwritten.
561 </p>
562 </dd>
565 </dt>
566 <dd>
567 <p>
569 write the resulting index in the named file. While the
570 command is operating, the original index file is locked
571 with the same mechanism as usual. The file must allow
572 to be rename(2)ed into from a temporary file that is
573 created next to the usual index file; typically this
574 means it needs to be on the same filesystem as the index
575 file itself, and you need write permission to the
576 directories the index file and index output file are
577 located in.
578 </p>
579 </dd>
581 --no-sparse-checkout
582 </dt>
583 <dd>
584 <p>
586 is true.
587 </p>
588 </dd>
591 </dt>
592 <dd>
593 <p>
594 The id of the tree object(s) to be read/merged.
595 </p>
596 </dd>
597 </dl></div>
598 </div>
601 <div class="paragraph"><p>If <tt>-m</tt> is specified, <em>git read-tree</em> can perform 3 kinds of
602 merge, a single tree merge if only 1 tree is given, a
604 provided.</p></div>
606 <div class="paragraph"><p>If only 1 tree is specified, <em>git read-tree</em> operates as if the user did not
608 given pathname, and the contents of the path match with the tree
609 being read, the stat info from the index is used. (In other words, the
611 <div class="paragraph"><p>That means that if you do a <tt>git read-tree -m <newtree></tt> followed by a
613 the stuff that really changed.</p></div>
614 <div class="paragraph"><p>This is used to avoid unnecessary false hits when <em>git diff-files</em> is
617 <div class="paragraph"><p>Typically, this is invoked as <tt>git read-tree -m $H $M</tt>, where $H
618 is the head commit of the current repository, and $M is the head
619 of a foreign tree, which is simply ahead of $H (i.e. we are in a
620 fast-forward situation).</p></div>
621 <div class="paragraph"><p>When two trees are specified, the user is telling <em>git read-tree</em>
622 the following:</p></div>
624 <li>
625 <p>
626 The current index and work tree is derived from $H, but
627 the user may have local changes in them since $H.
628 </p>
629 </li>
630 <li>
631 <p>
632 The user wants to fast-forward to $M.
633 </p>
634 </li>
635 </ol></div>
637 that no local change is lost as the result of this "merge".
640 refer to the presence of a path in the specified commit:</p></div>
651 <tbody>
652 <tr>
658 </tr>
659 <tr>
665 </tr>
666 <tr>
672 </tr>
673 <tr>
679 </tr>
680 <tr>
685 <td align="left" valign="top"><p class="table">use M if "initial checkout", keep index otherwise</p></td>
686 </tr>
687 <tr>
690 </tr>
691 </tbody>
692 </table>
693 </div>
696 <pre><tt> clean I==H I==M
697 ------------------
698 4 yes N/A N/A nothing nothing keep index
700 </div></div>
704 7 no N/A yes nothing exists keep index
705 8 yes N/A no nothing exists fail
707 </div></div>
711 11 no yes N/A exists nothing fail
712 12 yes no N/A exists nothing fail
714 </div></div>
717 <pre><tt> clean (H==M)
718 ------
719 14 yes exists exists keep index
721 </div></div>
724 <pre><tt> clean I==H I==M (H!=M)
725 ------------------
726 16 yes no no exists exists fail
727 17 no no no exists exists fail
728 18 yes no yes exists exists keep index
729 19 no no yes exists exists keep index
730 20 yes yes no exists exists use M
732 </div></div>
734 original index file. If the entry is not up to date,
736 operating under the -u flag.</p></div>
737 <div class="paragraph"><p>When this form of <em>git read-tree</em> returns successfully, you can
738 see which of the "local changes" that you made were carried forward by running
741 produced before such a two tree merge. This is because of cases
743 you picked it up via e-mail in a patch form), <tt>git diff-index
744 --cached $H</tt> would have told you about the change before this
746 output after the two-tree merge.</p></div>
748 rule logically should be to remove the path if the user staged the removal
749 of the path and then switching to a new branch. That however will prevent
750 the initial checkout from happening, so the rule is modified to use M (new
751 tree) only when the content of the index is empty. Otherwise the removal
752 of the path is kept as long as $H and $M are the same.</p></div>
754 <div class="paragraph"><p>Each "index" entry has two bits worth of "stage" state. stage 0 is the
756 <div class="paragraph"><p>However, when you do <em>git read-tree</em> with three trees, the "stage"
762 </div></div>
763 <div class="paragraph"><p>and you will end up with an index with all of the <tree1> entries in
766 branch into the current branch, we use the common ancestor tree
769 <div class="paragraph"><p>Furthermore, <em>git read-tree</em> has special-case logic that says: if you see
770 a file that matches in all respects in the following states, it
773 <li>
774 <p>
776 difference - the same work has been done on our branch in
778 </p>
779 </li>
780 <li>
781 <p>
785 it)
786 </p>
787 </li>
788 <li>
789 <p>
791 stage 2 (we did something while they did nothing)
792 </p>
793 </li>
794 </ul></div>
795 <div class="paragraph"><p>The <em>git write-tree</em> command refuses to write a nonsensical tree, and it
796 will complain about unmerged entries if it sees a single entry that is not
799 but it’s actually exactly what you want in order to do a fast
805 start a 3-way merge with an index file that is already
806 populated. Here is an outline of how the algorithm works:</p></div>
808 <li>
809 <p>
810 if a file exists in identical format in all three trees, it will
812 </p>
813 </li>
814 <li>
815 <p>
819 merged version.
820 </p>
821 </li>
822 <li>
823 <p>
824 the index file saves and restores with all this information, so you
825 can merge things incrementally, but as long as it has entries in
827 now the merge algorithm ends up being really simple:
828 </p>
830 <li>
831 <p>
832 you walk the index in order, and ignore all entries of stage 0,
833 since they’ve already been done.
834 </p>
835 </li>
836 <li>
837 <p>
839 know it’s been removed from both trees (it only existed in the
840 original tree), and you remove that entry.
841 </p>
842 </li>
843 <li>
844 <p>
846 of them, and turn the other into a "stage0" entry. Remove any
847 matching "stage1" entry if it exists too. .. all the normal
848 trivial rules ..
849 </p>
850 </li>
851 </ul></div>
852 </li>
853 </ul></div>
856 the files in the working tree as it merges each path and at the
857 end of a successful merge.</p></div>
859 populated, it is assumed that it represents the state of the
860 files in your work tree, and you can even have files with
861 changes unrecorded in the index file. It is further assumed
863 merge refuses to run if it finds an entry in the original index
866 changes, and mixing your random changes in an unrelated merge
867 commit. To illustrate, suppose you start from what has been
868 committed last to your repository:</p></div>
872 $ git checkout-index -f -u -a $JC</tt></pre>
873 </div></div>
874 <div class="paragraph"><p>You do random edits, without running <em>git update-index</em>. And then
875 you notice that the tip of your "upstream" tree has advanced
876 since you pulled from him:</p></div>
879 <pre><tt>$ git fetch git://.... linus
880 $ LT=`cat .git/FETCH_HEAD`</tt></pre>
881 </div></div>
883 some edits since. Three-way merge makes sure that you have not
884 added or modified index entries since $JC, and if you haven’t,
885 then does the right thing. So with the following sequence:</p></div>
888 <pre><tt>$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
889 $ git merge-index git-merge-one-file -a
890 $ echo "Merge with Linus" | \
891 git commit-tree `git write-tree` -p $JC -p $LT</tt></pre>
892 </div></div>
894 your work-in-progress changes, and your work tree would be
895 updated to the result of the merge.</p></div>
898 to run to prevent your changes from being lost.</p></div>
900 in the working tree. When you have local changes in a part of
901 the project that is not involved in the merge, your changes do
902 not interfere with the merge, and are kept intact. When they
904 complains loudly and fails without modifying anything). In such
905 a case, you can simply continue doing what you were in the
906 middle of doing, and when your working tree is ready (i.e. you
907 have finished your work-in-progress), attempt the merge again.</p></div>
908 </div>
913 Git whether a file on working directory is worth looking at.</p></div>
917 define the skip-worktree reference bitmap. When "git read-tree" needs
918 to update working directory, it will reset skip-worktree bit in index
919 based on this file, which uses the same syntax as .gitignore files.
920 If an entry matches a pattern in this file, skip-worktree will be
921 set on that entry. Otherwise, skip-worktree will be unset.</p></div>
922 <div class="paragraph"><p>Then it compares the new skip-worktree value with the previous one. If
923 skip-worktree turns from unset to set, it will add the corresponding
924 file back. If it turns from set to unset, that file will be removed.</p></div>
925 <div class="paragraph"><p>While <tt>$GIT_DIR/info/sparse-checkout</tt> is usually used to specify what
930 <pre><tt>*
931 !unwanted</tt></pre>
932 </div></div>
934 no longer want sparse checkout. You cannot just disable "sparse
935 checkout" because skip-worktree are still in the index and you working
936 directory is still sparsely populated. You should re-populate working
938 follows:</p></div>
942 </div></div>
944 read-tree" and similar commands is disabled by default. You need to
946 support.</p></div>
947 </div>
950 <div class="paragraph"><p><a href="git-write-tree.html">git-write-tree(1)</a>; <a href="git-ls-files.html">git-ls-files(1)</a>;
952 </div>
955 <div class="paragraph"><p>Written by Linus Torvalds <<a href="mailto:torvalds@osdl.org">torvalds@osdl.org</a>></p></div>
956 </div>
959 <div class="paragraph"><p>Documentation by David Greaves, Junio C Hamano and the git-list <<a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>>.</p></div>
960 </div>
964 </div>
968 </div>
969 </div>
970 </body>
971 </html>