]>
Commit | Line | Data |
---|---|---|
1 | git-read-tree(1) | |
2 | ================ | |
3 | ||
4 | NAME | |
5 | ---- | |
6 | git-read-tree - Reads tree information into the index | |
7 | ||
8 | ||
9 | SYNOPSIS | |
10 | -------- | |
11 | [verse] | |
12 | 'git read-tree' [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] | |
13 | [-u [--exclude-per-directory=<gitignore>] | -i]] | |
14 | [--index-output=<file>] [--no-sparse-checkout] | |
15 | (--empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]]) | |
16 | ||
17 | ||
18 | DESCRIPTION | |
19 | ----------- | |
20 | Reads the tree information given by <tree-ish> into the index, | |
21 | but does not actually *update* any of the files it "caches". (see: | |
22 | linkgit:git-checkout-index[1]) | |
23 | ||
24 | Optionally, it can merge a tree into the index, perform a | |
25 | fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m` | |
26 | flag. When used with `-m`, the `-u` flag causes it to also update | |
27 | the files in the work tree with the result of the merge. | |
28 | ||
29 | Trivial merges are done by 'git read-tree' itself. Only conflicting paths | |
30 | will be in unmerged state when 'git read-tree' returns. | |
31 | ||
32 | OPTIONS | |
33 | ------- | |
34 | -m:: | |
35 | Perform a merge, not just a read. The command will | |
36 | refuse to run if your index file has unmerged entries, | |
37 | indicating that you have not finished previous merge you | |
38 | started. | |
39 | ||
40 | --reset:: | |
41 | Same as -m, except that unmerged entries are discarded | |
42 | instead of failing. | |
43 | ||
44 | -u:: | |
45 | After a successful merge, update the files in the work | |
46 | tree with the result of the merge. | |
47 | ||
48 | -i:: | |
49 | Usually a merge requires the index file as well as the | |
50 | files in the working tree to be up to date with the | |
51 | current head commit, in order not to lose local | |
52 | changes. This flag disables the check with the working | |
53 | tree and is meant to be used when creating a merge of | |
54 | trees that are not directly related to the current | |
55 | working tree status into a temporary index file. | |
56 | ||
57 | -n:: | |
58 | --dry-run:: | |
59 | Check if the command would error out, without updating the index | |
60 | or the files in the working tree for real. | |
61 | ||
62 | -v:: | |
63 | Show the progress of checking files out. | |
64 | ||
65 | --trivial:: | |
66 | Restrict three-way merge by 'git read-tree' to happen | |
67 | only if there is no file-level merging required, instead | |
68 | of resolving merge for trivial cases and leaving | |
69 | conflicting files unresolved in the index. | |
70 | ||
71 | --aggressive:: | |
72 | Usually a three-way merge by 'git read-tree' resolves | |
73 | the merge for really trivial cases and leaves other | |
74 | cases unresolved in the index, so that porcelains can | |
75 | implement different merge policies. This flag makes the | |
76 | command resolve a few more cases internally: | |
77 | + | |
78 | * when one side removes a path and the other side leaves the path | |
79 | unmodified. The resolution is to remove that path. | |
80 | * when both sides remove a path. The resolution is to remove that path. | |
81 | * when both sides add a path identically. The resolution | |
82 | is to add that path. | |
83 | ||
84 | --prefix=<prefix>:: | |
85 | Keep the current index contents, and read the contents | |
86 | of the named tree-ish under the directory at `<prefix>`. | |
87 | The command will refuse to overwrite entries that already | |
88 | existed in the original index file. | |
89 | ||
90 | --exclude-per-directory=<gitignore>:: | |
91 | When running the command with `-u` and `-m` options, the | |
92 | merge result may need to overwrite paths that are not | |
93 | tracked in the current branch. The command usually | |
94 | refuses to proceed with the merge to avoid losing such a | |
95 | path. However this safety valve sometimes gets in the | |
96 | way. For example, it often happens that the other | |
97 | branch added a file that used to be a generated file in | |
98 | your branch, and the safety valve triggers when you try | |
99 | to switch to that branch after you ran `make` but before | |
100 | running `make clean` to remove the generated file. This | |
101 | option tells the command to read per-directory exclude | |
102 | file (usually '.gitignore') and allows such an untracked | |
103 | but explicitly ignored file to be overwritten. | |
104 | ||
105 | --index-output=<file>:: | |
106 | Instead of writing the results out to `$GIT_INDEX_FILE`, | |
107 | write the resulting index in the named file. While the | |
108 | command is operating, the original index file is locked | |
109 | with the same mechanism as usual. The file must allow | |
110 | to be rename(2)ed into from a temporary file that is | |
111 | created next to the usual index file; typically this | |
112 | means it needs to be on the same filesystem as the index | |
113 | file itself, and you need write permission to the | |
114 | directories the index file and index output file are | |
115 | located in. | |
116 | ||
117 | --[no-]recurse-submodules:: | |
118 | Using --recurse-submodules will update the content of all initialized | |
119 | submodules according to the commit recorded in the superproject by | |
120 | calling read-tree recursively, also setting the submodules HEAD to be | |
121 | detached at that commit. | |
122 | ||
123 | --no-sparse-checkout:: | |
124 | Disable sparse checkout support even if `core.sparseCheckout` | |
125 | is true. | |
126 | ||
127 | --empty:: | |
128 | Instead of reading tree object(s) into the index, just empty | |
129 | it. | |
130 | ||
131 | <tree-ish#>:: | |
132 | The id of the tree object(s) to be read/merged. | |
133 | ||
134 | ||
135 | MERGING | |
136 | ------- | |
137 | If `-m` is specified, 'git read-tree' can perform 3 kinds of | |
138 | merge, a single tree merge if only 1 tree is given, a | |
139 | fast-forward merge with 2 trees, or a 3-way merge if 3 or more trees are | |
140 | provided. | |
141 | ||
142 | ||
143 | Single Tree Merge | |
144 | ~~~~~~~~~~~~~~~~~ | |
145 | If only 1 tree is specified, 'git read-tree' operates as if the user did not | |
146 | specify `-m`, except that if the original index has an entry for a | |
147 | given pathname, and the contents of the path match with the tree | |
148 | being read, the stat info from the index is used. (In other words, the | |
149 | index's stat()s take precedence over the merged tree's). | |
150 | ||
151 | That means that if you do a `git read-tree -m <newtree>` followed by a | |
152 | `git checkout-index -f -u -a`, the 'git checkout-index' only checks out | |
153 | the stuff that really changed. | |
154 | ||
155 | This is used to avoid unnecessary false hits when 'git diff-files' is | |
156 | run after 'git read-tree'. | |
157 | ||
158 | ||
159 | Two Tree Merge | |
160 | ~~~~~~~~~~~~~~ | |
161 | ||
162 | Typically, this is invoked as `git read-tree -m $H $M`, where $H | |
163 | is the head commit of the current repository, and $M is the head | |
164 | of a foreign tree, which is simply ahead of $H (i.e. we are in a | |
165 | fast-forward situation). | |
166 | ||
167 | When two trees are specified, the user is telling 'git read-tree' | |
168 | the following: | |
169 | ||
170 | 1. The current index and work tree is derived from $H, but | |
171 | the user may have local changes in them since $H. | |
172 | ||
173 | 2. The user wants to fast-forward to $M. | |
174 | ||
175 | In this case, the `git read-tree -m $H $M` command makes sure | |
176 | that no local change is lost as the result of this "merge". | |
177 | Here are the "carry forward" rules, where "I" denotes the index, | |
178 | "clean" means that index and work tree coincide, and "exists"/"nothing" | |
179 | refer to the presence of a path in the specified commit: | |
180 | ||
181 | .... | |
182 | I H M Result | |
183 | ------------------------------------------------------- | |
184 | 0 nothing nothing nothing (does not happen) | |
185 | 1 nothing nothing exists use M | |
186 | 2 nothing exists nothing remove path from index | |
187 | 3 nothing exists exists, use M if "initial checkout", | |
188 | H == M keep index otherwise | |
189 | exists, fail | |
190 | H != M | |
191 | ||
192 | clean I==H I==M | |
193 | ------------------ | |
194 | 4 yes N/A N/A nothing nothing keep index | |
195 | 5 no N/A N/A nothing nothing keep index | |
196 | ||
197 | 6 yes N/A yes nothing exists keep index | |
198 | 7 no N/A yes nothing exists keep index | |
199 | 8 yes N/A no nothing exists fail | |
200 | 9 no N/A no nothing exists fail | |
201 | ||
202 | 10 yes yes N/A exists nothing remove path from index | |
203 | 11 no yes N/A exists nothing fail | |
204 | 12 yes no N/A exists nothing fail | |
205 | 13 no no N/A exists nothing fail | |
206 | ||
207 | clean (H==M) | |
208 | ------ | |
209 | 14 yes exists exists keep index | |
210 | 15 no exists exists keep index | |
211 | ||
212 | clean I==H I==M (H!=M) | |
213 | ------------------ | |
214 | 16 yes no no exists exists fail | |
215 | 17 no no no exists exists fail | |
216 | 18 yes no yes exists exists keep index | |
217 | 19 no no yes exists exists keep index | |
218 | 20 yes yes no exists exists use M | |
219 | 21 no yes no exists exists fail | |
220 | .... | |
221 | ||
222 | In all "keep index" cases, the index entry stays as in the | |
223 | original index file. If the entry is not up to date, | |
224 | 'git read-tree' keeps the copy in the work tree intact when | |
225 | operating under the -u flag. | |
226 | ||
227 | When this form of 'git read-tree' returns successfully, you can | |
228 | see which of the "local changes" that you made were carried forward by running | |
229 | `git diff-index --cached $M`. Note that this does not | |
230 | necessarily match what `git diff-index --cached $H` would have | |
231 | produced before such a two tree merge. This is because of cases | |
232 | 18 and 19 --- if you already had the changes in $M (e.g. maybe | |
233 | you picked it up via e-mail in a patch form), `git diff-index | |
234 | --cached $H` would have told you about the change before this | |
235 | merge, but it would not show in `git diff-index --cached $M` | |
236 | output after the two-tree merge. | |
237 | ||
238 | Case 3 is slightly tricky and needs explanation. The result from this | |
239 | rule logically should be to remove the path if the user staged the removal | |
240 | of the path and then switching to a new branch. That however will prevent | |
241 | the initial checkout from happening, so the rule is modified to use M (new | |
242 | tree) only when the content of the index is empty. Otherwise the removal | |
243 | of the path is kept as long as $H and $M are the same. | |
244 | ||
245 | 3-Way Merge | |
246 | ~~~~~~~~~~~ | |
247 | Each "index" entry has two bits worth of "stage" state. stage 0 is the | |
248 | normal one, and is the only one you'd see in any kind of normal use. | |
249 | ||
250 | However, when you do 'git read-tree' with three trees, the "stage" | |
251 | starts out at 1. | |
252 | ||
253 | This means that you can do | |
254 | ||
255 | ---------------- | |
256 | $ git read-tree -m <tree1> <tree2> <tree3> | |
257 | ---------------- | |
258 | ||
259 | and you will end up with an index with all of the <tree1> entries in | |
260 | "stage1", all of the <tree2> entries in "stage2" and all of the | |
261 | <tree3> entries in "stage3". When performing a merge of another | |
262 | branch into the current branch, we use the common ancestor tree | |
263 | as <tree1>, the current branch head as <tree2>, and the other | |
264 | branch head as <tree3>. | |
265 | ||
266 | Furthermore, 'git read-tree' has special-case logic that says: if you see | |
267 | a file that matches in all respects in the following states, it | |
268 | "collapses" back to "stage0": | |
269 | ||
270 | - stage 2 and 3 are the same; take one or the other (it makes no | |
271 | difference - the same work has been done on our branch in | |
272 | stage 2 and their branch in stage 3) | |
273 | ||
274 | - stage 1 and stage 2 are the same and stage 3 is different; take | |
275 | stage 3 (our branch in stage 2 did not do anything since the | |
276 | ancestor in stage 1 while their branch in stage 3 worked on | |
277 | it) | |
278 | ||
279 | - stage 1 and stage 3 are the same and stage 2 is different take | |
280 | stage 2 (we did something while they did nothing) | |
281 | ||
282 | The 'git write-tree' command refuses to write a nonsensical tree, and it | |
283 | will complain about unmerged entries if it sees a single entry that is not | |
284 | stage 0. | |
285 | ||
286 | OK, this all sounds like a collection of totally nonsensical rules, | |
287 | but it's actually exactly what you want in order to do a fast | |
288 | merge. The different stages represent the "result tree" (stage 0, aka | |
289 | "merged"), the original tree (stage 1, aka "orig"), and the two trees | |
290 | you are trying to merge (stage 2 and 3 respectively). | |
291 | ||
292 | The order of stages 1, 2 and 3 (hence the order of three | |
293 | <tree-ish> command-line arguments) are significant when you | |
294 | start a 3-way merge with an index file that is already | |
295 | populated. Here is an outline of how the algorithm works: | |
296 | ||
297 | - if a file exists in identical format in all three trees, it will | |
298 | automatically collapse to "merged" state by 'git read-tree'. | |
299 | ||
300 | - a file that has _any_ difference what-so-ever in the three trees | |
301 | will stay as separate entries in the index. It's up to "porcelain | |
302 | policy" to determine how to remove the non-0 stages, and insert a | |
303 | merged version. | |
304 | ||
305 | - the index file saves and restores with all this information, so you | |
306 | can merge things incrementally, but as long as it has entries in | |
307 | stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So | |
308 | now the merge algorithm ends up being really simple: | |
309 | ||
310 | * you walk the index in order, and ignore all entries of stage 0, | |
311 | since they've already been done. | |
312 | ||
313 | * if you find a "stage1", but no matching "stage2" or "stage3", you | |
314 | know it's been removed from both trees (it only existed in the | |
315 | original tree), and you remove that entry. | |
316 | ||
317 | * if you find a matching "stage2" and "stage3" tree, you remove one | |
318 | of them, and turn the other into a "stage0" entry. Remove any | |
319 | matching "stage1" entry if it exists too. .. all the normal | |
320 | trivial rules .. | |
321 | ||
322 | You would normally use 'git merge-index' with supplied | |
323 | 'git merge-one-file' to do this last step. The script updates | |
324 | the files in the working tree as it merges each path and at the | |
325 | end of a successful merge. | |
326 | ||
327 | When you start a 3-way merge with an index file that is already | |
328 | populated, it is assumed that it represents the state of the | |
329 | files in your work tree, and you can even have files with | |
330 | changes unrecorded in the index file. It is further assumed | |
331 | that this state is "derived" from the stage 2 tree. The 3-way | |
332 | merge refuses to run if it finds an entry in the original index | |
333 | file that does not match stage 2. | |
334 | ||
335 | This is done to prevent you from losing your work-in-progress | |
336 | changes, and mixing your random changes in an unrelated merge | |
337 | commit. To illustrate, suppose you start from what has been | |
338 | committed last to your repository: | |
339 | ||
340 | ---------------- | |
341 | $ JC=`git rev-parse --verify "HEAD^0"` | |
342 | $ git checkout-index -f -u -a $JC | |
343 | ---------------- | |
344 | ||
345 | You do random edits, without running 'git update-index'. And then | |
346 | you notice that the tip of your "upstream" tree has advanced | |
347 | since you pulled from him: | |
348 | ||
349 | ---------------- | |
350 | $ git fetch git://.... linus | |
351 | $ LT=`git rev-parse FETCH_HEAD` | |
352 | ---------------- | |
353 | ||
354 | Your work tree is still based on your HEAD ($JC), but you have | |
355 | some edits since. Three-way merge makes sure that you have not | |
356 | added or modified index entries since $JC, and if you haven't, | |
357 | then does the right thing. So with the following sequence: | |
358 | ||
359 | ---------------- | |
360 | $ git read-tree -m -u `git merge-base $JC $LT` $JC $LT | |
361 | $ git merge-index git-merge-one-file -a | |
362 | $ echo "Merge with Linus" | \ | |
363 | git commit-tree `git write-tree` -p $JC -p $LT | |
364 | ---------------- | |
365 | ||
366 | what you would commit is a pure merge between $JC and $LT without | |
367 | your work-in-progress changes, and your work tree would be | |
368 | updated to the result of the merge. | |
369 | ||
370 | However, if you have local changes in the working tree that | |
371 | would be overwritten by this merge, 'git read-tree' will refuse | |
372 | to run to prevent your changes from being lost. | |
373 | ||
374 | In other words, there is no need to worry about what exists only | |
375 | in the working tree. When you have local changes in a part of | |
376 | the project that is not involved in the merge, your changes do | |
377 | not interfere with the merge, and are kept intact. When they | |
378 | *do* interfere, the merge does not even start ('git read-tree' | |
379 | complains loudly and fails without modifying anything). In such | |
380 | a case, you can simply continue doing what you were in the | |
381 | middle of doing, and when your working tree is ready (i.e. you | |
382 | have finished your work-in-progress), attempt the merge again. | |
383 | ||
384 | ||
385 | SPARSE CHECKOUT | |
386 | --------------- | |
387 | ||
388 | "Sparse checkout" allows populating the working directory sparsely. | |
389 | It uses the skip-worktree bit (see linkgit:git-update-index[1]) to tell | |
390 | Git whether a file in the working directory is worth looking at. | |
391 | ||
392 | 'git read-tree' and other merge-based commands ('git merge', 'git | |
393 | checkout'...) can help maintaining the skip-worktree bitmap and working | |
394 | directory update. `$GIT_DIR/info/sparse-checkout` is used to | |
395 | define the skip-worktree reference bitmap. When 'git read-tree' needs | |
396 | to update the working directory, it resets the skip-worktree bit in the index | |
397 | based on this file, which uses the same syntax as .gitignore files. | |
398 | If an entry matches a pattern in this file, skip-worktree will not be | |
399 | set on that entry. Otherwise, skip-worktree will be set. | |
400 | ||
401 | Then it compares the new skip-worktree value with the previous one. If | |
402 | skip-worktree turns from set to unset, it will add the corresponding | |
403 | file back. If it turns from unset to set, that file will be removed. | |
404 | ||
405 | While `$GIT_DIR/info/sparse-checkout` is usually used to specify what | |
406 | files are in, you can also specify what files are _not_ in, using | |
407 | negate patterns. For example, to remove the file `unwanted`: | |
408 | ||
409 | ---------------- | |
410 | /* | |
411 | !unwanted | |
412 | ---------------- | |
413 | ||
414 | Another tricky thing is fully repopulating the working directory when you | |
415 | no longer want sparse checkout. You cannot just disable "sparse | |
416 | checkout" because skip-worktree bits are still in the index and your working | |
417 | directory is still sparsely populated. You should re-populate the working | |
418 | directory with the `$GIT_DIR/info/sparse-checkout` file content as | |
419 | follows: | |
420 | ||
421 | ---------------- | |
422 | /* | |
423 | ---------------- | |
424 | ||
425 | Then you can disable sparse checkout. Sparse checkout support in 'git | |
426 | read-tree' and similar commands is disabled by default. You need to | |
427 | turn `core.sparseCheckout` on in order to have sparse checkout | |
428 | support. | |
429 | ||
430 | ||
431 | SEE ALSO | |
432 | -------- | |
433 | linkgit:git-write-tree[1]; linkgit:git-ls-files[1]; | |
434 | linkgit:gitignore[5] | |
435 | ||
436 | GIT | |
437 | --- | |
438 | Part of the linkgit:git[1] suite |