| blob | 9f81e1d9de6a3efdf0b518aaeafd108adc2b20b4 |
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>
590 --empty
591 </dt>
592 <dd>
593 <p>
594 Instead of reading tree object(s) into the index, just empty
595 it.
596 </p>
597 </dd>
600 </dt>
601 <dd>
602 <p>
603 The id of the tree object(s) to be read/merged.
604 </p>
605 </dd>
606 </dl></div>
607 </div>
610 <div class="paragraph"><p>If <tt>-m</tt> is specified, <em>git read-tree</em> can perform 3 kinds of
611 merge, a single tree merge if only 1 tree is given, a
613 provided.</p></div>
615 <div class="paragraph"><p>If only 1 tree is specified, <em>git read-tree</em> operates as if the user did not
617 given pathname, and the contents of the path match with the tree
618 being read, the stat info from the index is used. (In other words, the
620 <div class="paragraph"><p>That means that if you do a <tt>git read-tree -m <newtree></tt> followed by a
622 the stuff that really changed.</p></div>
623 <div class="paragraph"><p>This is used to avoid unnecessary false hits when <em>git diff-files</em> is
626 <div class="paragraph"><p>Typically, this is invoked as <tt>git read-tree -m $H $M</tt>, where $H
627 is the head commit of the current repository, and $M is the head
628 of a foreign tree, which is simply ahead of $H (i.e. we are in a
629 fast-forward situation).</p></div>
630 <div class="paragraph"><p>When two trees are specified, the user is telling <em>git read-tree</em>
631 the following:</p></div>
633 <li>
634 <p>
635 The current index and work tree is derived from $H, but
636 the user may have local changes in them since $H.
637 </p>
638 </li>
639 <li>
640 <p>
641 The user wants to fast-forward to $M.
642 </p>
643 </li>
644 </ol></div>
646 that no local change is lost as the result of this "merge".
649 refer to the presence of a path in the specified commit:</p></div>
652 <pre><tt> I H M Result
653 -------------------------------------------------------
654 0 nothing nothing nothing (does not happen)
655 1 nothing nothing exists use M
656 2 nothing exists nothing remove path from index
658 H == M keep index otherwise
659 exists, fail
660 H != M</tt></pre>
661 </div></div>
664 <pre><tt> clean I==H I==M
665 ------------------
666 4 yes N/A N/A nothing nothing keep index
668 </div></div>
672 7 no N/A yes nothing exists keep index
673 8 yes N/A no nothing exists fail
675 </div></div>
679 11 no yes N/A exists nothing fail
680 12 yes no N/A exists nothing fail
682 </div></div>
685 <pre><tt> clean (H==M)
686 ------
687 14 yes exists exists keep index
689 </div></div>
692 <pre><tt> clean I==H I==M (H!=M)
693 ------------------
694 16 yes no no exists exists fail
695 17 no no no exists exists fail
696 18 yes no yes exists exists keep index
697 19 no no yes exists exists keep index
698 20 yes yes no exists exists use M
700 </div></div>
702 original index file. If the entry is not up to date,
704 operating under the -u flag.</p></div>
705 <div class="paragraph"><p>When this form of <em>git read-tree</em> returns successfully, you can
706 see which of the "local changes" that you made were carried forward by running
709 produced before such a two tree merge. This is because of cases
711 you picked it up via e-mail in a patch form), <tt>git diff-index
712 --cached $H</tt> would have told you about the change before this
714 output after the two-tree merge.</p></div>
716 rule logically should be to remove the path if the user staged the removal
717 of the path and then switching to a new branch. That however will prevent
718 the initial checkout from happening, so the rule is modified to use M (new
719 tree) only when the content of the index is empty. Otherwise the removal
720 of the path is kept as long as $H and $M are the same.</p></div>
722 <div class="paragraph"><p>Each "index" entry has two bits worth of "stage" state. stage 0 is the
724 <div class="paragraph"><p>However, when you do <em>git read-tree</em> with three trees, the "stage"
730 </div></div>
731 <div class="paragraph"><p>and you will end up with an index with all of the <tree1> entries in
734 branch into the current branch, we use the common ancestor tree
737 <div class="paragraph"><p>Furthermore, <em>git read-tree</em> has special-case logic that says: if you see
738 a file that matches in all respects in the following states, it
741 <li>
742 <p>
744 difference - the same work has been done on our branch in
746 </p>
747 </li>
748 <li>
749 <p>
753 it)
754 </p>
755 </li>
756 <li>
757 <p>
759 stage 2 (we did something while they did nothing)
760 </p>
761 </li>
762 </ul></div>
763 <div class="paragraph"><p>The <em>git write-tree</em> command refuses to write a nonsensical tree, and it
764 will complain about unmerged entries if it sees a single entry that is not
767 but it’s actually exactly what you want in order to do a fast
773 start a 3-way merge with an index file that is already
774 populated. Here is an outline of how the algorithm works:</p></div>
776 <li>
777 <p>
778 if a file exists in identical format in all three trees, it will
780 </p>
781 </li>
782 <li>
783 <p>
787 merged version.
788 </p>
789 </li>
790 <li>
791 <p>
792 the index file saves and restores with all this information, so you
793 can merge things incrementally, but as long as it has entries in
795 now the merge algorithm ends up being really simple:
796 </p>
798 <li>
799 <p>
800 you walk the index in order, and ignore all entries of stage 0,
801 since they’ve already been done.
802 </p>
803 </li>
804 <li>
805 <p>
807 know it’s been removed from both trees (it only existed in the
808 original tree), and you remove that entry.
809 </p>
810 </li>
811 <li>
812 <p>
814 of them, and turn the other into a "stage0" entry. Remove any
815 matching "stage1" entry if it exists too. .. all the normal
816 trivial rules ..
817 </p>
818 </li>
819 </ul></div>
820 </li>
821 </ul></div>
824 the files in the working tree as it merges each path and at the
825 end of a successful merge.</p></div>
827 populated, it is assumed that it represents the state of the
828 files in your work tree, and you can even have files with
829 changes unrecorded in the index file. It is further assumed
831 merge refuses to run if it finds an entry in the original index
834 changes, and mixing your random changes in an unrelated merge
835 commit. To illustrate, suppose you start from what has been
836 committed last to your repository:</p></div>
840 $ git checkout-index -f -u -a $JC</tt></pre>
841 </div></div>
842 <div class="paragraph"><p>You do random edits, without running <em>git update-index</em>. And then
843 you notice that the tip of your "upstream" tree has advanced
844 since you pulled from him:</p></div>
847 <pre><tt>$ git fetch git://.... linus
848 $ LT=`cat .git/FETCH_HEAD`</tt></pre>
849 </div></div>
851 some edits since. Three-way merge makes sure that you have not
852 added or modified index entries since $JC, and if you haven’t,
853 then does the right thing. So with the following sequence:</p></div>
856 <pre><tt>$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
857 $ git merge-index git-merge-one-file -a
858 $ echo "Merge with Linus" | \
859 git commit-tree `git write-tree` -p $JC -p $LT</tt></pre>
860 </div></div>
862 your work-in-progress changes, and your work tree would be
863 updated to the result of the merge.</p></div>
866 to run to prevent your changes from being lost.</p></div>
868 in the working tree. When you have local changes in a part of
869 the project that is not involved in the merge, your changes do
870 not interfere with the merge, and are kept intact. When they
872 complains loudly and fails without modifying anything). In such
873 a case, you can simply continue doing what you were in the
874 middle of doing, and when your working tree is ready (i.e. you
875 have finished your work-in-progress), attempt the merge again.</p></div>
876 </div>
881 Git whether a file on working directory is worth looking at.</p></div>
885 define the skip-worktree reference bitmap. When "git read-tree" needs
886 to update working directory, it will reset skip-worktree bit in index
887 based on this file, which uses the same syntax as .gitignore files.
888 If an entry matches a pattern in this file, skip-worktree will be
889 set on that entry. Otherwise, skip-worktree will be unset.</p></div>
890 <div class="paragraph"><p>Then it compares the new skip-worktree value with the previous one. If
891 skip-worktree turns from unset to set, it will add the corresponding
892 file back. If it turns from set to unset, that file will be removed.</p></div>
893 <div class="paragraph"><p>While <tt>$GIT_DIR/info/sparse-checkout</tt> is usually used to specify what
898 <pre><tt>*
899 !unwanted</tt></pre>
900 </div></div>
902 no longer want sparse checkout. You cannot just disable "sparse
903 checkout" because skip-worktree are still in the index and you working
904 directory is still sparsely populated. You should re-populate working
906 follows:</p></div>
910 </div></div>
912 read-tree" and similar commands is disabled by default. You need to
914 support.</p></div>
915 </div>
918 <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>;
920 </div>
924 </div>
928 </div>
929 </div>
930 </body>
931 </html>