diff options
Diffstat (limited to 'Documentation/git-read-tree.txt')
| -rw-r--r-- | Documentation/git-read-tree.txt | 17 |
1 files changed, 13 insertions, 4 deletions
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index 844cfda8d2..11bd9c0adc 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -8,7 +8,7 @@ git-read-tree - Reads tree information into the index SYNOPSIS -------- -'git-read-tree' (<tree-ish> | [[-m [--aggressive]| --reset] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]]) +'git-read-tree' (<tree-ish> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]]) DESCRIPTION @@ -63,6 +63,15 @@ OPTIONS * when both sides adds a path identically. The resolution is to add that path. +--prefix=<prefix>/:: + Keep the current index contents, and read the contents + of named tree-ish under directory at `<prefix>`. The + original index file cannot have anything at the path + `<prefix>` itself, and have nothing in `<prefix>/` + directory. Note that the `<prefix>/` value must end + with a slash. + + <tree-ish#>:: The id of the tree object(s) to be read/merged. @@ -205,7 +214,7 @@ 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 @@ -226,7 +235,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, @@ -257,7 +266,7 @@ file that does not match stage 2. 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"` |