]>
Commit | Line | Data |
---|---|---|
2cf565c5 DG |
1 | git-read-tree(1) |
2 | ================ | |
3 | v0.1, May 2005 | |
4 | ||
5 | NAME | |
6 | ---- | |
7 | git-read-tree - Reads tree information into the directory cache | |
8 | ||
9 | ||
10 | SYNOPSIS | |
11 | -------- | |
ccef66b5 JH |
12 | 'git-read-tree' (<tree-ish> | [-m [-u]] <tree-ish1> [<tree-ish2> [<tree-ish3>]]) |
13 | ||
2cf565c5 DG |
14 | |
15 | DESCRIPTION | |
16 | ----------- | |
ccef66b5 | 17 | Reads the tree information given by <tree-ish> into the directory cache, |
c1bdacf9 | 18 | but does not actually *update* any of the files it "caches". (see: |
215a7ad1 | 19 | git-checkout-index) |
2cf565c5 | 20 | |
ccef66b5 JH |
21 | Optionally, it can merge a tree into the cache, perform a |
22 | fast-forward (i.e. 2-way) merge, or a 3-way merge, with the -m | |
23 | flag. When used with -m, the -u flag causes it to also update | |
24 | the files in the work tree with the result of the merge. | |
2cf565c5 DG |
25 | |
26 | Trivial merges are done by "git-read-tree" itself. Only conflicting paths | |
27 | will be in unmerged state when "git-read-tree" returns. | |
28 | ||
29 | OPTIONS | |
30 | ------- | |
31 | -m:: | |
ccef66b5 JH |
32 | Perform a merge, not just a read. |
33 | ||
34 | -u:: | |
35 | After a successful merge, update the files in the work | |
36 | tree with the result of the merge. | |
2cf565c5 DG |
37 | |
38 | <tree-ish#>:: | |
39 | The id of the tree object(s) to be read/merged. | |
40 | ||
41 | ||
42 | Merging | |
43 | ------- | |
2c6e4771 | 44 | If '-m' is specified, "git-read-tree" can perform 3 kinds of |
ccef66b5 JH |
45 | merge, a single tree merge if only 1 tree is given, a |
46 | fast-forward merge with 2 trees, or a 3-way merge if 3 trees are | |
2cf565c5 DG |
47 | provided. |
48 | ||
ccef66b5 | 49 | |
2cf565c5 DG |
50 | Single Tree Merge |
51 | ~~~~~~~~~~~~~~~~~ | |
52 | If only 1 tree is specified, git-read-tree operates as if the user did not | |
53 | specify '-m', except that if the original cache has an entry for a | |
2c6e4771 | 54 | given pathname, and the contents of the path matches with the tree |
2cf565c5 | 55 | being read, the stat info from the cache is used. (In other words, the |
2c6e4771 | 56 | cache's stat()s take precedence over the merged tree's). |
2cf565c5 DG |
57 | |
58 | That means that if you do a "git-read-tree -m <newtree>" followed by a | |
215a7ad1 | 59 | "git-checkout-index -f -u -a", the "git-checkout-index" only checks out |
2cf565c5 DG |
60 | the stuff that really changed. |
61 | ||
62 | This is used to avoid unnecessary false hits when "git-diff-files" is | |
63 | run after git-read-tree. | |
64 | ||
c8596009 JH |
65 | |
66 | Two Tree Merge | |
67 | ~~~~~~~~~~~~~~ | |
68 | ||
69 | Typically, this is invoked as "git-read-tree -m $H $M", where $H | |
70 | is the head commit of the current repository, and $M is the head | |
71 | of a foreign tree, which is simply ahead of $H (i.e. we are in a | |
72 | fast forward situation). | |
73 | ||
74 | When two trees are specified, the user is telling git-read-tree | |
75 | the following: | |
76 | ||
77 | (1) The current index and work tree is derived from $H, but | |
78 | the user may have local changes in them since $H; | |
79 | ||
80 | (2) The user wants to fast-forward to $M. | |
81 | ||
82 | In this case, the "git-read-tree -m $H $M" command makes sure | |
83 | that no local change is lost as the result of this "merge". | |
84 | Here are the "carry forward" rules: | |
85 | ||
86 | I (index) H M Result | |
87 | ------------------------------------------------------- | |
88 | 0 nothing nothing nothing (does not happen) | |
89 | 1 nothing nothing exists use M | |
90 | 2 nothing exists nothing remove path from cache | |
91 | 3 nothing exists exists use M | |
92 | ||
93 | clean I==H I==M | |
94 | ------------------ | |
95 | 4 yes N/A N/A nothing nothing keep index | |
96 | 5 no N/A N/A nothing nothing keep index | |
97 | ||
98 | 6 yes N/A yes nothing exists keep index | |
99 | 7 no N/A yes nothing exists keep index | |
100 | 8 yes N/A no nothing exists fail | |
101 | 9 no N/A no nothing exists fail | |
102 | ||
103 | 10 yes yes N/A exists nothing remove path from cache | |
104 | 11 no yes N/A exists nothing fail | |
105 | 12 yes no N/A exists nothing fail | |
106 | 13 no no N/A exists nothing fail | |
107 | ||
108 | clean (H=M) | |
109 | ------ | |
110 | 14 yes exists exists keep index | |
111 | 15 no exists exists keep index | |
112 | ||
113 | clean I==H I==M (H!=M) | |
114 | ------------------ | |
115 | 16 yes no no exists exists fail | |
116 | 17 no no no exists exists fail | |
117 | 18 yes no yes exists exists keep index | |
118 | 19 no no yes exists exists keep index | |
119 | 20 yes yes no exists exists use M | |
120 | 21 no yes no exists exists fail | |
121 | ||
122 | In all "keep index" cases, the cache entry stays as in the | |
123 | original index file. If the entry were not up to date, | |
124 | git-read-tree keeps the copy in the work tree intact when | |
125 | operating under the -u flag. | |
126 | ||
127 | When this form of git-read-tree returns successfully, you can | |
128 | see what "local changes" you made are carried forward by running | |
215a7ad1 JH |
129 | "git-diff-index --cached $M". Note that this does not |
130 | necessarily match "git-diff-index --cached $H" would have | |
c8596009 JH |
131 | produced before such a two tree merge. This is because of cases |
132 | 18 and 19 --- if you already had the changes in $M (e.g. maybe | |
215a7ad1 | 133 | you picked it up via e-mail in a patch form), "git-diff-index |
c8596009 | 134 | --cached $H" would have told you about the change before this |
215a7ad1 | 135 | merge, but it would not show in "git-diff-index --cached $M" |
c8596009 JH |
136 | output after two-tree merge. |
137 | ||
138 | ||
2cf565c5 DG |
139 | 3-Way Merge |
140 | ~~~~~~~~~~~ | |
141 | Each "index" entry has two bits worth of "stage" state. stage 0 is the | |
142 | normal one, and is the only one you'd see in any kind of normal use. | |
143 | ||
144 | However, when you do "git-read-tree" with three trees, the "stage" | |
145 | starts out at 1. | |
146 | ||
147 | This means that you can do | |
148 | ||
149 | git-read-tree -m <tree1> <tree2> <tree3> | |
150 | ||
151 | and you will end up with an index with all of the <tree1> entries in | |
152 | "stage1", all of the <tree2> entries in "stage2" and all of the | |
153 | <tree3> entries in "stage3". | |
154 | ||
155 | Furthermore, "git-read-tree" has special-case logic that says: if you see | |
156 | a file that matches in all respects in the following states, it | |
157 | "collapses" back to "stage0": | |
158 | ||
159 | - stage 2 and 3 are the same; take one or the other (it makes no | |
160 | difference - the same work has been done on stage 2 and 3) | |
161 | ||
162 | - stage 1 and stage 2 are the same and stage 3 is different; take | |
163 | stage 3 (some work has been done on stage 3) | |
164 | ||
165 | - stage 1 and stage 3 are the same and stage 2 is different take | |
166 | stage 2 (some work has been done on stage 2) | |
167 | ||
168 | The "git-write-tree" command refuses to write a nonsensical tree, and it | |
169 | will complain about unmerged entries if it sees a single entry that is not | |
170 | stage 0. | |
171 | ||
172 | Ok, this all sounds like a collection of totally nonsensical rules, | |
173 | but it's actually exactly what you want in order to do a fast | |
174 | merge. The different stages represent the "result tree" (stage 0, aka | |
175 | "merged"), the original tree (stage 1, aka "orig"), and the two trees | |
176 | you are trying to merge (stage 2 and 3 respectively). | |
177 | ||
ccef66b5 JH |
178 | The order of stages 1, 2 and 3 (hence the order of three |
179 | <tree-ish> command line arguments) are significant when you | |
180 | start a 3-way merge with an index file that is already | |
181 | populated. Here is an outline of how the algorithm works: | |
2cf565c5 DG |
182 | |
183 | - if a file exists in identical format in all three trees, it will | |
ccef66b5 | 184 | automatically collapse to "merged" state by git-read-tree. |
2cf565c5 DG |
185 | |
186 | - a file that has _any_ difference what-so-ever in the three trees | |
2c6e4771 | 187 | will stay as separate entries in the index. It's up to "porcelain |
2cf565c5 | 188 | policy" to determine how to remove the non-0 stages, and insert a |
ccef66b5 | 189 | merged version. |
2cf565c5 DG |
190 | |
191 | - the index file saves and restores with all this information, so you | |
192 | can merge things incrementally, but as long as it has entries in | |
193 | stages 1/2/3 (ie "unmerged entries") you can't write the result. So | |
194 | now the merge algorithm ends up being really simple: | |
195 | ||
196 | * you walk the index in order, and ignore all entries of stage 0, | |
197 | since they've already been done. | |
198 | ||
199 | * if you find a "stage1", but no matching "stage2" or "stage3", you | |
200 | know it's been removed from both trees (it only existed in the | |
201 | original tree), and you remove that entry. | |
202 | ||
203 | * if you find a matching "stage2" and "stage3" tree, you remove one | |
204 | of them, and turn the other into a "stage0" entry. Remove any | |
205 | matching "stage1" entry if it exists too. .. all the normal | |
206 | trivial rules .. | |
207 | ||
215a7ad1 JH |
208 | You would normally use "git-merge-index" with supplied |
209 | "git-merge-one-file" to do this last step. The script | |
ccef66b5 JH |
210 | does not touch the files in the work tree, and the entire merge |
211 | happens in the index file. In other words, there is no need to | |
212 | worry about what is in the working directory, since it is never | |
213 | shown and never used. | |
214 | ||
215 | When you start a 3-way merge with an index file that is already | |
216 | populated, it is assumed that it represents the state of the | |
217 | files in your work tree, and you can even have files with | |
218 | changes unrecorded in the index file. It is further assumed | |
219 | that this state is "derived" from the stage 2 tree. The 3-way | |
220 | merge refuses to run if it finds an entry in the original index | |
221 | file that does not match stage 2. | |
222 | ||
223 | This is done to prevent you from losing your work-in-progress | |
224 | changes. To illustrate, suppose you start from what has been | |
225 | commited last to your repository: | |
226 | ||
227 | $ JC=`cat .git/HEAD` | |
215a7ad1 | 228 | $ git-checkout-index -f -u -a $JC |
ccef66b5 | 229 | |
215a7ad1 | 230 | You do random edits, without running git-update-index. And then |
ccef66b5 JH |
231 | you notice that the tip of your "upstream" tree has advanced |
232 | since you pulled from him: | |
233 | ||
215a7ad1 | 234 | $ git-fetch rsync://.... linus |
ccef66b5 JH |
235 | $ LT=`cat .git/MERGE_HEAD` |
236 | ||
237 | Your work tree is still based on your HEAD ($JC), but you have | |
238 | some edits since. Three-way merge makes sure that you have not | |
239 | added or modified cache entries since $JC, and if you haven't, | |
240 | then does the right thing. So with the following sequence: | |
241 | ||
242 | $ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT | |
215a7ad1 | 243 | $ git-merge-index git-merge-one-file -a |
ccef66b5 JH |
244 | $ echo "Merge with Linus" | \ |
245 | git-commit-tree `git-write-tree` -p $JC -p $LT | |
246 | ||
247 | what you would commit is a pure merge between $JC and LT without | |
248 | your work-in-progress changes, and your work tree would be | |
249 | updated to the result of the merge. | |
250 | ||
2cf565c5 | 251 | |
c1bdacf9 DG |
252 | See Also |
253 | -------- | |
254 | link:git-write-tree.html[git-write-tree]; link:git-ls-files.html[git-ls-files] | |
2cf565c5 DG |
255 | |
256 | ||
257 | Author | |
258 | ------ | |
259 | Written by Linus Torvalds <torvalds@osdl.org> | |
260 | ||
261 | Documentation | |
262 | -------------- | |
263 | Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. | |
264 | ||
265 | GIT | |
266 | --- | |
267 | Part of the link:git.html[git] suite | |
268 |