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