diff options
Diffstat (limited to 'Documentation/git-read-tree.txt')
| -rw-r--r-- | Documentation/git-read-tree.txt | 361 |
1 files changed, 262 insertions, 99 deletions
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index e1be6cc0bc..c4bde6509e 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -1,47 +1,135 @@ git-read-tree(1) ================ -v0.1, May 2005 NAME ---- -git-read-tree - Reads tree information into the directory cache +git-read-tree - Reads tree information into the index SYNOPSIS -------- -'git-read-tree' (<tree-ish> | [-m [-u]] <tree-ish1> [<tree-ish2> [<tree-ish3>]]) +[verse] +'git read-tree' [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] + [-u [--exclude-per-directory=<gitignore>] | -i]] + [--index-output=<file>] [--no-sparse-checkout] + (--empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]]) DESCRIPTION ----------- -Reads the tree information given by <tree-ish> into the directory cache, +Reads the tree information given by <tree-ish> into the index, but does not actually *update* any of the files it "caches". (see: -git-checkout-cache) +linkgit:git-checkout-index[1]) -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 +Optionally, it can merge a tree into the index, 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. +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. + Perform a merge, not just a read. The command will + refuse to run if your index file has unmerged entries, + indicating that you have not finished previous merge you + started. + +--reset:: + Same as -m, except that unmerged entries are discarded + instead of failing. -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 to be 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. + +-n:: +--dry-run:: + Check if the command would error out, without updating the index + nor the files in the working tree for real. + +-v:: + Show the progress of checking files out. + +--trivial:: + Restrict three-way merge by 'git read-tree' to happen + only if there is no file-level merging required, instead + of resolving merge for trivial cases and leaving + conflicting files unresolved in the index. + +--aggressive:: + Usually a three-way merge by 'git read-tree' resolves + the merge for really trivial cases and leaves other + cases unresolved in the index, so that porcelains can + implement different merge policies. This flag makes the + command resolve a few more cases internally: ++ +* when one side removes a path and the other side leaves the path + unmodified. The resolution is to remove that path. +* when both sides remove a path. The resolution is to remove that path. +* when both sides add a path identically. The resolution + is to add that path. + +--prefix=<prefix>/:: + Keep the current index contents, and read the contents + of the named tree-ish under the directory at `<prefix>`. + The command will refuse to overwrite entries that already + existed in the original index file. Note that the `<prefix>/` + value must end with a slash. + +--exclude-per-directory=<gitignore>:: + When running the command with `-u` and `-m` options, the + merge result may need to overwrite paths that are not + tracked in the current branch. The command usually + refuses to proceed with the merge to avoid losing such a + path. However this safety valve sometimes gets in the + way. For example, it often happens that the other + branch added a file that used to be a generated file in + your branch, and the safety valve triggers when you try + to switch to that branch after you ran `make` but before + running `make clean` to remove the generated file. This + option tells the command to read per-directory exclude + file (usually '.gitignore') and allows such an untracked + but explicitly ignored file to be overwritten. + +--index-output=<file>:: + Instead of writing the results out to `$GIT_INDEX_FILE`, + write the resulting index in the named file. While the + command is operating, the original index file is locked + with the same mechanism as usual. The file must allow + to be rename(2)ed into from a temporary file that is + created next to the usual index file; typically this + means it needs to be on the same filesystem as the index + file itself, and you need write permission to the + directories the index file and index output file are + located in. + +--no-sparse-checkout:: + Disable sparse checkout support even if `core.sparseCheckout` + is true. + +--empty:: + Instead of reading tree object(s) into the index, just empty + it. + <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 +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. @@ -49,63 +137,68 @@ 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 +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 match 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 the stuff that really changed. -This is used to avoid unnecessary false hits when "git-diff-files" is -run after git-read-tree. +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 +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). +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 - the user may have local changes in them since $H; + 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. + 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: +Here are the "carry forward" rules, where "I" denotes the index, +"clean" means that index and work tree coincide, and "exists"/"nothing" +refer to the presence of a path in the specified commit: - I (index) H M Result + I 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 + 0 nothing nothing nothing (does not happen) + 1 nothing nothing exists use M + 2 nothing exists nothing remove path from index + 3 nothing exists exists, use M if "initial checkout", + H == M keep index otherwise + exists, fail + H != 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 + 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 + 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 + 10 yes yes N/A exists nothing remove path from index 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) + clean (H==M) ------ 14 yes exists exists keep index 15 no exists exists keep index @@ -119,57 +212,71 @@ Here are the "carry forward" rules: 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 +In all "keep index" cases, the index entry stays as in the +original index file. If the entry is 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 +When this form of 'git read-tree' returns successfully, you can +see which of the "local changes" that you made were carried forward by running +`git diff-index --cached $M`. Note that this does not +necessarily match what `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-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. - +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 the two-tree merge. + +Case 3 is slightly tricky and needs explanation. The result from this +rule logically should be to remove the path if the user staged the removal +of the path and then switching to a new branch. That however will prevent +the initial checkout from happening, so the rule is modified to use M (new +tree) only when the content of the index is empty. Otherwise the removal +of the path is kept as long as $H and $M are the same. 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" +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> +---------------- +$ 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". +<tree3> entries in "stage3". When performing a merge of another +branch into the current branch, we use the common ancestor tree +as <tree1>, the current branch head as <tree2>, and the other +branch head as <tree3>. -Furthermore, "git-read-tree" has special-case logic that says: if you see +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) + difference - the same work has been done on our branch in + stage 2 and their branch in stage 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 3 (our branch in stage 2 did not do anything since the + ancestor in stage 1 while their branch in stage 3 worked on + it) - stage 1 and stage 3 are the same and stage 2 is different take - stage 2 (some work has been done on stage 2) + stage 2 (we did something while they did nothing) -The "git-write-tree" command refuses to write a nonsensical tree, and it +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, +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 @@ -181,7 +288,7 @@ 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. + 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 @@ -190,7 +297,7 @@ populated. Here is an outline of how the algorithm works: - 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 + stages 1/2/3 (i.e., "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, @@ -205,12 +312,10 @@ populated. Here is an outline of how the algorithm works: 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. +You would normally use 'git merge-index' with supplied +'git merge-one-file' to do this last step. The script updates +the files in the working tree as it merges each path and at the +end of a successful merge. 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 @@ -221,48 +326,106 @@ 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: +changes, and mixing your random changes in an unrelated merge +commit. To illustrate, suppose you start from what has been +committed last to your repository: - $ JC=`cat .git/HEAD` - $ git-checkout-cache -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-cache. 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-script rsync://.... linus - $ LT=`cat .git/MERGE_HEAD` +---------------- +$ git fetch git://.... linus +$ LT=`git rev-parse FETCH_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, +added or modified index 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 +---------------- +$ 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 +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 +However, if you have local changes in the working tree that +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 +in the working tree. When you have local changes in a part of +the project that is not involved in the merge, your changes do +not interfere with the merge, and are kept intact. When they +*do* interfere, the merge does not even start ('git read-tree' +complains loudly and fails without modifying anything). In such +a case, you can simply continue doing what you were in the +middle of doing, and when your working tree is ready (i.e. you +have finished your work-in-progress), attempt the merge again. + + +Sparse checkout +--------------- + +"Sparse checkout" allows populating the working directory sparsely. +It uses the skip-worktree bit (see linkgit:git-update-index[1]) to tell +Git whether a file in the working directory is worth looking at. + +'git read-tree' and other merge-based commands ('git merge', 'git +checkout'...) can help maintaining the skip-worktree bitmap and working +directory update. `$GIT_DIR/info/sparse-checkout` is used to +define the skip-worktree reference bitmap. When 'git read-tree' needs +to update the working directory, it resets the skip-worktree bit in the index +based on this file, which uses the same syntax as .gitignore files. +If an entry matches a pattern in this file, skip-worktree will not be +set on that entry. Otherwise, skip-worktree will be set. + +Then it compares the new skip-worktree value with the previous one. If +skip-worktree turns from set to unset, it will add the corresponding +file back. If it turns from unset to set, that file will be removed. + +While `$GIT_DIR/info/sparse-checkout` is usually used to specify what +files are in, you can also specify what files are _not_ in, using +negate patterns. For example, to remove the file `unwanted`: + +---------------- +/* +!unwanted +---------------- + +Another tricky thing is fully repopulating the working directory when you +no longer want sparse checkout. You cannot just disable "sparse +checkout" because skip-worktree bits are still in the index and your working +directory is still sparsely populated. You should re-populate the working +directory with the `$GIT_DIR/info/sparse-checkout` file content as +follows: + +---------------- +/* +---------------- + +Then you can disable sparse checkout. Sparse checkout support in 'git +read-tree' and similar commands is disabled by default. You need to +turn `core.sparseCheckout` on in order to have sparse checkout +support. + + +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>. +linkgit:git-write-tree[1]; linkgit:git-ls-files[1]; +linkgit:gitignore[5] GIT --- -Part of the link:git.html[git] suite - +Part of the linkgit:git[1] suite |