| git-read-tree(1) | |
| ================ | |
| v0.1, May 2005 | |
| NAME | |
| ---- | |
| git-read-tree - Reads tree information into the directory cache | |
| SYNOPSIS | |
| -------- | |
| 'git-read-tree' (<tree-ish> | [-m [-u]] <tree-ish1> [<tree-ish2> [<tree-ish3>]]) | |
| DESCRIPTION | |
| ----------- | |
| Reads the tree information given by <tree-ish> into the directory cache, | |
| but does not actually *update* any of the files it "caches". (see: | |
| git-checkout-cache) | |
| Optionally, it can merge a tree into the cache, perform a | |
| fast-forward (i.e. 2-way) merge, or a 3-way merge, with the -m | |
| flag. When used with -m, the -u flag causes it to also update | |
| the files in the work tree with the result of the merge. | |
| Trivial merges are done by "git-read-tree" itself. Only conflicting paths | |
| will be in unmerged state when "git-read-tree" returns. | |
| OPTIONS | |
| ------- | |
| -m:: | |
| Perform a merge, not just a read. | |
| -u:: | |
| After a successful merge, update the files in the work | |
| tree with the result of the merge. | |
| <tree-ish#>:: | |
| The id of the tree object(s) to be read/merged. | |
| Merging | |
| ------- | |
| If '-m' is specified, "git-read-tree" can perform 3 kinds of | |
| merge, a single tree merge if only 1 tree is given, a | |
| fast-forward merge with 2 trees, or a 3-way merge if 3 trees are | |
| provided. | |
| Single Tree Merge | |
| ~~~~~~~~~~~~~~~~~ | |
| If only 1 tree is specified, git-read-tree operates as if the user did not | |
| specify '-m', except that if the original cache has an entry for a | |
| given pathname, and the contents of the path matches with the tree | |
| being read, the stat info from the cache is used. (In other words, the | |
| cache's stat()s take precedence over the merged tree's). | |
| That means that if you do a "git-read-tree -m <newtree>" followed by a | |
| "git-checkout-cache -f -u -a", the "git-checkout-cache" only checks out | |
| the stuff that really changed. | |
| This is used to avoid unnecessary false hits when "git-diff-files" is | |
| run after git-read-tree. | |
| Two Tree Merge | |
| ~~~~~~~~~~~~~~ | |
| Typically, this is invoked as "git-read-tree -m $H $M", where $H | |
| is the head commit of the current repository, and $M is the head | |
| of a foreign tree, which is simply ahead of $H (i.e. we are in a | |
| fast forward situation). | |
| When two trees are specified, the user is telling git-read-tree | |
| the following: | |
| (1) The current index and work tree is derived from $H, but | |
| the user may have local changes in them since $H; | |
| (2) The user wants to fast-forward to $M. | |
| In this case, the "git-read-tree -m $H $M" command makes sure | |
| that no local change is lost as the result of this "merge". | |
| Here are the "carry forward" rules: | |
| I (index) H M Result | |
| ------------------------------------------------------- | |
| 0 nothing nothing nothing (does not happen) | |
| 1 nothing nothing exists use M | |
| 2 nothing exists nothing remove path from cache | |
| 3 nothing exists exists use M | |
| clean I==H I==M | |
| ------------------ | |
| 4 yes N/A N/A nothing nothing keep index | |
| 5 no N/A N/A nothing nothing keep index | |
| 6 yes N/A yes nothing exists keep index | |
| 7 no N/A yes nothing exists keep index | |
| 8 yes N/A no nothing exists fail | |
| 9 no N/A no nothing exists fail | |
| 10 yes yes N/A exists nothing remove path from cache | |
| 11 no yes N/A exists nothing fail | |
| 12 yes no N/A exists nothing fail | |
| 13 no no N/A exists nothing fail | |
| clean (H=M) | |
| ------ | |
| 14 yes exists exists keep index | |
| 15 no exists exists keep index | |
| clean I==H I==M (H!=M) | |
| ------------------ | |
| 16 yes no no exists exists fail | |
| 17 no no no exists exists fail | |
| 18 yes no yes exists exists keep index | |
| 19 no no yes exists exists keep index | |
| 20 yes yes no exists exists use M | |
| 21 no yes no exists exists fail | |
| In all "keep index" cases, the cache entry stays as in the | |
| original index file. If the entry were not up to date, | |
| git-read-tree keeps the copy in the work tree intact when | |
| operating under the -u flag. | |
| When this form of git-read-tree returns successfully, you can | |
| see what "local changes" you made are carried forward by running | |
| "git-diff-cache --cached $M". Note that this does not | |
| necessarily match "git-diff-cache --cached $H" would have | |
| produced before such a two tree merge. This is because of cases | |
| 18 and 19 --- if you already had the changes in $M (e.g. maybe | |
| you picked it up via e-mail in a patch form), "git-diff-cache | |
| --cached $H" would have told you about the change before this | |
| merge, but it would not show in "git-diff-cache --cached $M" | |
| output after two-tree merge. | |
| 3-Way Merge | |
| ~~~~~~~~~~~ | |
| Each "index" entry has two bits worth of "stage" state. stage 0 is the | |
| normal one, and is the only one you'd see in any kind of normal use. | |
| However, when you do "git-read-tree" with three trees, the "stage" | |
| starts out at 1. | |
| This means that you can do | |
| git-read-tree -m <tree1> <tree2> <tree3> | |
| and you will end up with an index with all of the <tree1> entries in | |
| "stage1", all of the <tree2> entries in "stage2" and all of the | |
| <tree3> entries in "stage3". | |
| Furthermore, "git-read-tree" has special-case logic that says: if you see | |
| a file that matches in all respects in the following states, it | |
| "collapses" back to "stage0": | |
| - stage 2 and 3 are the same; take one or the other (it makes no | |
| difference - the same work has been done on stage 2 and 3) | |
| - stage 1 and stage 2 are the same and stage 3 is different; take | |
| stage 3 (some work has been done on stage 3) | |
| - stage 1 and stage 3 are the same and stage 2 is different take | |
| stage 2 (some work has been done on stage 2) | |
| The "git-write-tree" command refuses to write a nonsensical tree, and it | |
| will complain about unmerged entries if it sees a single entry that is not | |
| stage 0. | |
| Ok, this all sounds like a collection of totally nonsensical rules, | |
| but it's actually exactly what you want in order to do a fast | |
| merge. The different stages represent the "result tree" (stage 0, aka | |
| "merged"), the original tree (stage 1, aka "orig"), and the two trees | |
| you are trying to merge (stage 2 and 3 respectively). | |
| The order of stages 1, 2 and 3 (hence the order of three | |
| <tree-ish> command line arguments) are significant when you | |
| start a 3-way merge with an index file that is already | |
| populated. Here is an outline of how the algorithm works: | |
| - if a file exists in identical format in all three trees, it will | |
| automatically collapse to "merged" state by git-read-tree. | |
| - a file that has _any_ difference what-so-ever in the three trees | |
| will stay as separate entries in the index. It's up to "porcelain | |
| policy" to determine how to remove the non-0 stages, and insert a | |
| merged version. | |
| - the index file saves and restores with all this information, so you | |
| can merge things incrementally, but as long as it has entries in | |
| stages 1/2/3 (ie "unmerged entries") you can't write the result. So | |
| now the merge algorithm ends up being really simple: | |
| * you walk the index in order, and ignore all entries of stage 0, | |
| since they've already been done. | |
| * if you find a "stage1", but no matching "stage2" or "stage3", you | |
| know it's been removed from both trees (it only existed in the | |
| original tree), and you remove that entry. | |
| * if you find a matching "stage2" and "stage3" tree, you remove one | |
| of them, and turn the other into a "stage0" entry. Remove any | |
| matching "stage1" entry if it exists too. .. all the normal | |
| trivial rules .. | |
| You would normally use "git-merge-cache" with supplied | |
| "git-merge-one-file-script" to do this last step. The script | |
| does not touch the files in the work tree, and the entire merge | |
| happens in the index file. In other words, there is no need to | |
| worry about what is in the working directory, since it is never | |
| shown and never used. | |
| When you start a 3-way merge with an index file that is already | |
| populated, it is assumed that it represents the state of the | |
| files in your work tree, and you can even have files with | |
| changes unrecorded in the index file. It is further assumed | |
| that this state is "derived" from the stage 2 tree. The 3-way | |
| merge refuses to run if it finds an entry in the original index | |
| file that does not match stage 2. | |
| This is done to prevent you from losing your work-in-progress | |
| changes. To illustrate, suppose you start from what has been | |
| commited last to your repository: | |
| $ JC=`cat .git/HEAD` | |
| $ git-checkout-cache -f -u -a $JC | |
| You do random edits, without running git-update-cache. And then | |
| you notice that the tip of your "upstream" tree has advanced | |
| since you pulled from him: | |
| $ git-fetch-script rsync://.... linus | |
| $ LT=`cat .git/MERGE_HEAD` | |
| Your work tree is still based on your HEAD ($JC), but you have | |
| some edits since. Three-way merge makes sure that you have not | |
| added or modified cache entries since $JC, and if you haven't, | |
| then does the right thing. So with the following sequence: | |
| $ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT | |
| $ git-merge-cache git-merge-one-file-script -a | |
| $ echo "Merge with Linus" | \ | |
| git-commit-tree `git-write-tree` -p $JC -p $LT | |
| what you would commit is a pure merge between $JC and LT without | |
| your work-in-progress changes, and your work tree would be | |
| updated to the result of the merge. | |
| See Also | |
| -------- | |
| link:git-write-tree.html[git-write-tree]; link:git-ls-files.html[git-ls-files] | |
| Author | |
| ------ | |
| Written by Linus Torvalds <torvalds@osdl.org> | |
| Documentation | |
| -------------- | |
| Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. | |
| GIT | |
| --- | |
| Part of the link:git.html[git] suite | |