about summary refs log tree commit diff
path: root/third_party/git/Documentation/git-read-tree.txt
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/git/Documentation/git-read-tree.txt')
-rw-r--r--third_party/git/Documentation/git-read-tree.txt443
1 files changed, 0 insertions, 443 deletions
diff --git a/third_party/git/Documentation/git-read-tree.txt b/third_party/git/Documentation/git-read-tree.txt
deleted file mode 100644
index d271842608..0000000000
--- a/third_party/git/Documentation/git-read-tree.txt
+++ /dev/null
@@ -1,443 +0,0 @@
-git-read-tree(1)
-================
-
-NAME
-----
-git-read-tree - Reads tree information into the index
-
-
-SYNOPSIS
---------
-[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 index,
-but does not actually *update* any of the files it "caches". (see:
-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`
-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.  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. When used with `-u`, updates leading to loss of
-	working tree changes will not abort the operation.
-
--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
-	or 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.
-
---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-]recurse-submodules::
-	Using --recurse-submodules will update the content of all initialized
-	submodules according to the commit recorded in the superproject by
-	calling read-tree recursively, also setting the submodules HEAD to be
-	detached at that commit.
-
---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.
-
--q::
---quiet::
-	Quiet, suppress feedback messages.
-
-<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 or more 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 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'.
-
-
-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, 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                   H        M        Result
-       -------------------------------------------------------
-     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
-
-     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 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)
-       ------
-     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 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 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-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"
-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".  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
-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 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 (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 (we did something while they did nothing)
-
-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 (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,
-    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 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
-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, 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=`git rev-parse --verify "HEAD^0"`
-$ 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 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 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-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.
-
-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
---------
-linkgit:git-write-tree[1]; linkgit:git-ls-files[1];
-linkgit:gitignore[5]
-
-GIT
----
-Part of the linkgit:git[1] suite