| blob | 3f96eb50d10aa3368d5580cb579810310a196922 |
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 }
129 }
133 }
135 /* Block element titles. */
143 }
146 }
150 }
153 }
156 }
162 }
168 }
176 }
181 }
185 }
189 }
190 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
193 }
202 }
206 }
211 }
217 dl {
220 }
221 dt {
226 }
229 }
233 }
236 }
239 }
242 }
245 }
248 }
255 }
259 }
263 }
264 tfoot {
266 }
269 }
272 }
273 /* Because the table frame attribute is overriden by CSS in most browsers. */
276 }
280 }
284 }
290 }
293 }
296 }
302 }
305 }
309 }
313 }
317 }
321 }
326 }
330 }
340 }
345 }
347 div#toc {
349 }
351 div#toctitle {
358 }
363 }
367 }
371 }
375 }
376 /* Overrides for manpage documents */
377 h1 {
382 }
383 h2 {
385 }
388 }
392 }
394 /* Workarounds for IE6's broken and incomplete CSS2. */
400 }
407 }
413 }
418 }
422 }
426 }
431 }
433 /* IE6 sets dynamically generated links as visited. */
435 </style>
437 /*<![CDATA[*/
441 /////////////////////////////////////////////////////////////////////
442 // Table Of Contents generator
443 /////////////////////////////////////////////////////////////////////
445 /* Author: Mihai Bazon, September 2002
446 * http://students.infoiasi.ro/~mishoo
447 *
448 * Table Of Content generator
449 * Version: 0.4
450 *
451 * Feel free to use this script under the terms of the GNU General Public
452 * License, as long as you do not remove or alter this notice.
453 */
455 /* modified by Troy D. Hanson, September 2006. License: GPL */
456 /* modified by Stuart Rackham, 2006, 2009. License: GPL */
458 // toclevels = 1..4.
468 }
470 }
476 }
481 // Function that scans the DOM tree for header elements (the DOM2
482 // nodeIterator API would be a better technique but not supported by all
483 // browsers).
490 }
492 }
493 }
494 }
497 }
512 }
515 },
518 /////////////////////////////////////////////////////////////////////
519 // Footnotes generator
520 /////////////////////////////////////////////////////////////////////
522 /* Based on footnote generation code from:
523 * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
524 */
534 n++;
535 // Use [\s\S] in place of . so multi-line matches work.
536 // Because JavaScript has no s (dotall) regex flag.
547 }
548 }
552 // Process footnoterefs.
561 }
562 }
563 }
564 }
566 }
567 /*]]>*/
568 </script>
569 </head>
570 <body>
572 <h1>
573 git-read-tree(1) Manual Page
574 </h1>
577 <p>git-read-tree -
578 Reads tree information into the index
579 </p>
580 </div>
581 </div>
586 <div class="verseblock-content"><em>git read-tree</em> [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>]
591 </div></div>
592 </div>
601 the files in the work tree with the result of the merge.</p></div>
602 <div class="paragraph"><p>Trivial merges are done by <em>git read-tree</em> itself. Only conflicting paths
604 </div>
609 -m
610 </dt>
611 <dd>
612 <p>
613 Perform a merge, not just a read. The command will
614 refuse to run if your index file has unmerged entries,
615 indicating that you have not finished previous merge you
616 started.
617 </p>
618 </dd>
620 --reset
621 </dt>
622 <dd>
623 <p>
624 Same as -m, except that unmerged entries are discarded
625 instead of failing.
626 </p>
627 </dd>
629 -u
630 </dt>
631 <dd>
632 <p>
633 After a successful merge, update the files in the work
634 tree with the result of the merge.
635 </p>
636 </dd>
638 -i
639 </dt>
640 <dd>
641 <p>
642 Usually a merge requires the index file as well as the
643 files in the working tree to be up to date with the
644 current head commit, in order not to lose local
645 changes. This flag disables the check with the working
646 tree and is meant to be used when creating a merge of
647 trees that are not directly related to the current
648 working tree status into a temporary index file.
649 </p>
650 </dd>
652 -n
653 </dt>
655 --dry-run
656 </dt>
657 <dd>
658 <p>
659 Check if the command would error out, without updating the index
660 nor the files in the working tree for real.
661 </p>
662 </dd>
664 -v
665 </dt>
666 <dd>
667 <p>
668 Show the progress of checking files out.
669 </p>
670 </dd>
672 --trivial
673 </dt>
674 <dd>
675 <p>
677 only if there is no file-level merging required, instead
678 of resolving merge for trivial cases and leaving
679 conflicting files unresolved in the index.
680 </p>
681 </dd>
683 --aggressive
684 </dt>
685 <dd>
686 <p>
688 the merge for really trivial cases and leaves other
689 cases unresolved in the index, so that porcelains can
690 implement different merge policies. This flag makes the
691 command resolve a few more cases internally:
692 </p>
694 <li>
695 <p>
696 when one side removes a path and the other side leaves the path
697 unmodified. The resolution is to remove that path.
698 </p>
699 </li>
700 <li>
701 <p>
702 when both sides remove a path. The resolution is to remove that path.
703 </p>
704 </li>
705 <li>
706 <p>
707 when both sides add a path identically. The resolution
708 is to add that path.
709 </p>
710 </li>
711 </ul></div>
712 </dd>
715 </dt>
716 <dd>
717 <p>
718 Keep the current index contents, and read the contents
720 original index file cannot have anything at the path
723 with a slash.
724 </p>
725 </dd>
728 </dt>
729 <dd>
730 <p>
732 merge result may need to overwrite paths that are not
733 tracked in the current branch. The command usually
734 refuses to proceed with the merge to avoid losing such a
735 path. However this safety valve sometimes gets in the
736 way. For example, it often happens that the other
737 branch added a file that used to be a generated file in
738 your branch, and the safety valve triggers when you try
741 option tells the command to read per-directory exclude
743 but explicitly ignored file to be overwritten.
744 </p>
745 </dd>
748 </dt>
749 <dd>
750 <p>
752 write the resulting index in the named file. While the
753 command is operating, the original index file is locked
754 with the same mechanism as usual. The file must allow
755 to be rename(2)ed into from a temporary file that is
756 created next to the usual index file; typically this
757 means it needs to be on the same filesystem as the index
758 file itself, and you need write permission to the
759 directories the index file and index output file are
760 located in.
761 </p>
762 </dd>
764 --no-sparse-checkout
765 </dt>
766 <dd>
767 <p>
769 is true.
770 </p>
771 </dd>
773 --empty
774 </dt>
775 <dd>
776 <p>
777 Instead of reading tree object(s) into the index, just empty
778 it.
779 </p>
780 </dd>
783 </dt>
784 <dd>
785 <p>
786 The id of the tree object(s) to be read/merged.
787 </p>
788 </dd>
789 </dl></div>
790 </div>
793 <div class="paragraph"><p>If <tt>-m</tt> is specified, <em>git read-tree</em> can perform 3 kinds of
794 merge, a single tree merge if only 1 tree is given, a
796 provided.</p></div>
798 <div class="paragraph"><p>If only 1 tree is specified, <em>git read-tree</em> operates as if the user did not
800 given pathname, and the contents of the path match with the tree
801 being read, the stat info from the index is used. (In other words, the
803 <div class="paragraph"><p>That means that if you do a <tt>git read-tree -m <newtree></tt> followed by a
805 the stuff that really changed.</p></div>
806 <div class="paragraph"><p>This is used to avoid unnecessary false hits when <em>git diff-files</em> is
809 <div class="paragraph"><p>Typically, this is invoked as <tt>git read-tree -m $H $M</tt>, where $H
810 is the head commit of the current repository, and $M is the head
811 of a foreign tree, which is simply ahead of $H (i.e. we are in a
812 fast-forward situation).</p></div>
813 <div class="paragraph"><p>When two trees are specified, the user is telling <em>git read-tree</em>
814 the following:</p></div>
816 <li>
817 <p>
818 The current index and work tree is derived from $H, but
819 the user may have local changes in them since $H.
820 </p>
821 </li>
822 <li>
823 <p>
824 The user wants to fast-forward to $M.
825 </p>
826 </li>
827 </ol></div>
829 that no local change is lost as the result of this "merge".
832 refer to the presence of a path in the specified commit:</p></div>
835 <pre><tt> I H M Result
836 -------------------------------------------------------
837 0 nothing nothing nothing (does not happen)
838 1 nothing nothing exists use M
839 2 nothing exists nothing remove path from index
841 H == M keep index otherwise
842 exists, fail
843 H != M</tt></pre>
844 </div></div>
847 <pre><tt> clean I==H I==M
848 ------------------
849 4 yes N/A N/A nothing nothing keep index
851 </div></div>
855 7 no N/A yes nothing exists keep index
856 8 yes N/A no nothing exists fail
858 </div></div>
862 11 no yes N/A exists nothing fail
863 12 yes no N/A exists nothing fail
865 </div></div>
868 <pre><tt> clean (H==M)
869 ------
870 14 yes exists exists keep index
872 </div></div>
875 <pre><tt> clean I==H I==M (H!=M)
876 ------------------
877 16 yes no no exists exists fail
878 17 no no no exists exists fail
879 18 yes no yes exists exists keep index
880 19 no no yes exists exists keep index
881 20 yes yes no exists exists use M
883 </div></div>
885 original index file. If the entry is not up to date,
887 operating under the -u flag.</p></div>
888 <div class="paragraph"><p>When this form of <em>git read-tree</em> returns successfully, you can
889 see which of the "local changes" that you made were carried forward by running
892 produced before such a two tree merge. This is because of cases
894 you picked it up via e-mail in a patch form), <tt>git diff-index
895 --cached $H</tt> would have told you about the change before this
897 output after the two-tree merge.</p></div>
899 rule logically should be to remove the path if the user staged the removal
900 of the path and then switching to a new branch. That however will prevent
901 the initial checkout from happening, so the rule is modified to use M (new
902 tree) only when the content of the index is empty. Otherwise the removal
903 of the path is kept as long as $H and $M are the same.</p></div>
905 <div class="paragraph"><p>Each "index" entry has two bits worth of "stage" state. stage 0 is the
907 <div class="paragraph"><p>However, when you do <em>git read-tree</em> with three trees, the "stage"
913 </div></div>
914 <div class="paragraph"><p>and you will end up with an index with all of the <tree1> entries in
917 branch into the current branch, we use the common ancestor tree
920 <div class="paragraph"><p>Furthermore, <em>git read-tree</em> has special-case logic that says: if you see
921 a file that matches in all respects in the following states, it
924 <li>
925 <p>
927 difference - the same work has been done on our branch in
929 </p>
930 </li>
931 <li>
932 <p>
936 it)
937 </p>
938 </li>
939 <li>
940 <p>
942 stage 2 (we did something while they did nothing)
943 </p>
944 </li>
945 </ul></div>
946 <div class="paragraph"><p>The <em>git write-tree</em> command refuses to write a nonsensical tree, and it
947 will complain about unmerged entries if it sees a single entry that is not
950 but it’s actually exactly what you want in order to do a fast
956 start a 3-way merge with an index file that is already
957 populated. Here is an outline of how the algorithm works:</p></div>
959 <li>
960 <p>
961 if a file exists in identical format in all three trees, it will
963 </p>
964 </li>
965 <li>
966 <p>
970 merged version.
971 </p>
972 </li>
973 <li>
974 <p>
975 the index file saves and restores with all this information, so you
976 can merge things incrementally, but as long as it has entries in
978 now the merge algorithm ends up being really simple:
979 </p>
981 <li>
982 <p>
983 you walk the index in order, and ignore all entries of stage 0,
984 since they’ve already been done.
985 </p>
986 </li>
987 <li>
988 <p>
990 know it’s been removed from both trees (it only existed in the
991 original tree), and you remove that entry.
992 </p>
993 </li>
994 <li>
995 <p>
997 of them, and turn the other into a "stage0" entry. Remove any
998 matching "stage1" entry if it exists too. .. all the normal
999 trivial rules ..
1000 </p>
1001 </li>
1002 </ul></div>
1003 </li>
1004 </ul></div>
1007 the files in the working tree as it merges each path and at the
1008 end of a successful merge.</p></div>
1010 populated, it is assumed that it represents the state of the
1011 files in your work tree, and you can even have files with
1012 changes unrecorded in the index file. It is further assumed
1014 merge refuses to run if it finds an entry in the original index
1017 changes, and mixing your random changes in an unrelated merge
1018 commit. To illustrate, suppose you start from what has been
1019 committed last to your repository:</p></div>
1023 $ git checkout-index -f -u -a $JC</tt></pre>
1024 </div></div>
1025 <div class="paragraph"><p>You do random edits, without running <em>git update-index</em>. And then
1026 you notice that the tip of your "upstream" tree has advanced
1027 since you pulled from him:</p></div>
1030 <pre><tt>$ git fetch git://.... linus
1031 $ LT=`cat .git/FETCH_HEAD`</tt></pre>
1032 </div></div>
1034 some edits since. Three-way merge makes sure that you have not
1035 added or modified index entries since $JC, and if you haven’t,
1036 then does the right thing. So with the following sequence:</p></div>
1039 <pre><tt>$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
1040 $ git merge-index git-merge-one-file -a
1041 $ echo "Merge with Linus" | \
1042 git commit-tree `git write-tree` -p $JC -p $LT</tt></pre>
1043 </div></div>
1045 your work-in-progress changes, and your work tree would be
1046 updated to the result of the merge.</p></div>
1049 to run to prevent your changes from being lost.</p></div>
1051 in the working tree. When you have local changes in a part of
1052 the project that is not involved in the merge, your changes do
1053 not interfere with the merge, and are kept intact. When they
1055 complains loudly and fails without modifying anything). In such
1056 a case, you can simply continue doing what you were in the
1057 middle of doing, and when your working tree is ready (i.e. you
1058 have finished your work-in-progress), attempt the merge again.</p></div>
1059 </div>
1063 It uses the skip-worktree bit (see <a href="git-update-index.html">git-update-index(1)</a>) to tell
1064 Git whether a file in the working directory is worth looking at.</p></div>
1065 <div class="paragraph"><p><em>git read-tree</em> and other merge-based commands (<em>git merge</em>, <em>git
1069 to update the working directory, it resets the skip-worktree bit in the index
1070 based on this file, which uses the same syntax as .gitignore files.
1071 If an entry matches a pattern in this file, skip-worktree will not be
1072 set on that entry. Otherwise, skip-worktree will be set.</p></div>
1073 <div class="paragraph"><p>Then it compares the new skip-worktree value with the previous one. If
1074 skip-worktree turns from set to unset, it will add the corresponding
1075 file back. If it turns from unset to set, that file will be removed.</p></div>
1076 <div class="paragraph"><p>While <tt>$GIT_DIR/info/sparse-checkout</tt> is usually used to specify what
1081 <pre><tt>/*
1082 !unwanted</tt></pre>
1083 </div></div>
1084 <div class="paragraph"><p>Another tricky thing is fully repopulating the working directory when you
1085 no longer want sparse checkout. You cannot just disable "sparse
1086 checkout" because skip-worktree bits are still in the index and your working
1087 directory is still sparsely populated. You should re-populate the working
1089 follows:</p></div>
1093 </div></div>
1094 <div class="paragraph"><p>Then you can disable sparse checkout. Sparse checkout support in <em>git
1095 read-tree</em> and similar commands is disabled by default. You need to
1097 support.</p></div>
1098 </div>
1101 <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>;
1103 </div>
1107 </div>
1108 </div>
1113 </div>
1114 </div>
1115 </body>
1116 </html>