![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index 1f21d95684a476a7e771ef166536415b5fe81a3c..74c5478ba18763de1703f0c8c08c20f1aac02ac0 100644 (file)
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
trees that are not directly related to the current
working tree status into a temporary index file.
+--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"`
See Also
--------
-gitlink:git-write-tree[1]; gitlink:git-ls-files[1]
+gitlink:git-write-tree[1]; gitlink:git-ls-files[1];
+gitlink:gitignore[5]
Author
@@ -329,4 +362,3 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
-