You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
278 lines
9.9 KiB
278 lines
9.9 KiB
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|-i]] <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-index) |
|
|
|
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. |
|
|
|
-i:: |
|
Usually a merge requires the index file as well as the |
|
files in the working tree are up to date with the |
|
current head commit, in order not to lose local |
|
changes. This flag disables the check with the working |
|
tree and is meant to be used when creating a merge of |
|
trees that are not directly related to the current |
|
working tree status into a temporary index file. |
|
|
|
|
|
<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-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 |
|
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-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 |
|
--cached $H" would have told you about the change before this |
|
merge, but it would not show in "git-diff-index --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-index" with supplied |
|
"git-merge-one-file" 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-index -f -u -a $JC |
|
|
|
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 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-index git-merge-one-file -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 |
|
-------- |
|
gitlink:git-write-tree[1]; gitlink:git-ls-files[1] |
|
|
|
|
|
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 gitlink:git[7] suite |
|
|
|
|