![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index c95ad9f1451fd5db2e4fcbdb64f606f81f39ff14..0c7cc6b940a0c39e89e114b41e69bf6aba631196 100644 (file)
SYNOPSIS
--------
-'git-read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+'git read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
DESCRIPTION
Single Tree Merge
~~~~~~~~~~~~~~~~~
-If only 1 tree is specified, git-read-tree operates as if the user did not
+If only 1 tree is specified, `git-read-tree` operates as if the user did not
specify `-m`, except that if the original index has an entry for a
given pathname, and the contents of the path matches with the tree
being read, the stat info from the index is used. (In other words, the
index'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-index -f -u -a`, the `git-checkout-index` only checks out
+That means that if you do a `git read-tree -m <newtree>` followed by a
+`git checkout-index -f -u -a`, the `git-checkout-index` only checks out
the stuff that really changed.
This is used to avoid unnecessary false hits when `git-diff-files` is
Two Tree Merge
~~~~~~~~~~~~~~
-Typically, this is invoked as `git-read-tree -m $H $M`, where $H
+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
+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
2. The user wants to fast-forward to $M.
-In this case, the `git-read-tree -m $H $M` command makes sure
+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:
In all "keep index" cases, the index 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
+`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
+When this form of `git-read-tree` returns successfully, you can
see what "local changes" you made are carried forward by running
-`git-diff-index --cached $M`. Note that this does not
-necessarily match `git-diff-index --cached $H` would have
+`git diff-index --cached $M`. Note that this does not
+necessarily match `git diff-index --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-index
+you picked it up via e-mail in a patch form), `git diff-index
--cached $H` would have told you about the change before this
-merge, but it would not show in `git-diff-index --cached $M`
+merge, but it would not show in `git diff-index --cached $M`
output after two-tree merge.
This means that you can do
----------------
-$ git-read-tree -m <tree1> <tree2> <tree3>
+$ git read-tree -m <tree1> <tree2> <tree3>
----------------
and you will end up with an index with all of the <tree1> entries in
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.
+ 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
committed last to your repository:
----------------
-$ JC=`git-rev-parse --verify "HEAD^0"`
-$ git-checkout-index -f -u -a $JC
+$ JC=`git rev-parse --verify "HEAD^0"`
+$ git checkout-index -f -u -a $JC
----------------
-You do random edits, without running git-update-index. And then
+You do random edits, without running `git-update-index`. And then
you notice that the tip of your "upstream" tree has advanced
since you pulled from him:
----------------
-$ git-fetch git://.... linus
+$ git fetch git://.... linus
$ LT=`cat .git/FETCH_HEAD`
----------------
then does the right thing. So with the following sequence:
----------------
-$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
-$ git-merge-index git-merge-one-file -a
+$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
+$ git merge-index git-merge-one-file -a
$ echo "Merge with Linus" | \
- git-commit-tree `git-write-tree` -p $JC -p $LT
+ git commit-tree `git write-tree` -p $JC -p $LT
----------------
what you would commit is a pure merge between $JC and $LT without
updated to the result of the merge.
However, if you have local changes in the working tree that
-would be overwritten by this merge,`git-read-tree` will refuse
+would be overwritten by this merge, `git-read-tree` will refuse
to run to prevent your changes from being lost.
In other words, there is no need to worry about what exists only
have finished your work-in-progress), attempt the merge again.
-See Also
+SEE ALSO
--------
linkgit:git-write-tree[1]; linkgit:git-ls-files[1];
linkgit:gitignore[5]
@@ -364,4 +364,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
-Part of the linkgit:git[7] suite
+Part of the linkgit:git[1] suite