SYNOPSIS
--------
-'git-read-tree' (<tree-ish> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] <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
-----------
Reads the tree information given by <tree-ish> into the index,
but does not actually *update* any of the files it "caches". (see:
-gitlink:git-checkout-index[1])
+linkgit:git-checkout-index[1])
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`
trees that are not directly related to the current
working tree status into a temporary index file.
+-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
directory. 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.
<tree-ish#>::
The id of the tree object(s) to be read/merged.
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
- 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,
This is done to prevent you from losing your work-in-progress
changes, and mixing your random changes in an unrelated merge
commit. To illustrate, suppose you start from what has been
-commited last to your repository:
+committed last to your repository:
----------------
$ JC=`git-rev-parse --verify "HEAD^0"`
have finished your work-in-progress), attempt the merge again.
-See Also
+SEE ALSO
--------
-gitlink:git-write-tree[1]; gitlink:git-ls-files[1]
+linkgit:git-write-tree[1]; linkgit:git-ls-files[1];
+linkgit:gitignore[5]
Author
GIT
---
-Part of the gitlink:git[7] suite
-
+Part of the linkgit:git[1] suite