index 1a57f580717e55afcdb463dc9acbb20b7b0dc218..0c7cc6b940a0c39e89e114b41e69bf6aba631196 100644 (file)
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
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
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
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
$ 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:
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