X-Git-Url: https://git.octo.it/?a=blobdiff_plain;f=Documentation%2Fgit-pull.txt;h=51577fcbe638981baf1870006eef633be304e26b;hb=ae448e3854d8b6e7e37aa88fa3917f5dd97f3210;hp=ec10a2f409a6cd3d7340cfc934c53ccd5a00f5f0;hpb=87ce294c9129879f717f8749cae1c659e18a3823;p=git.git

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index ec10a2f4..51577fcb 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -3,7 +3,7 @@ git-pull(1)
 
 NAME
 ----
-git-pull - Pull and merge from another repository.
+git-pull - Pull and merge from another repository
 
 
 SYNOPSIS
@@ -20,54 +20,18 @@ Note that you can use `.` (current directory) as the
 <repository> to pull from the local repository -- this is useful
 when merging local branches into the current branch.
 
+
 OPTIONS
 -------
+include::merge-options.txt[]
+
+include::fetch-options.txt[]
+
 include::pull-fetch-param.txt[]
 
--a, \--append::
-	Append ref names and object names of fetched refs to the
-	existing contents of `$GIT_DIR/FETCH_HEAD`.  Without this
-	option old data in `$GIT_DIR/FETCH_HEAD` will be overwritten.
-
-include::merge-pull-opts.txt[]
-
-
-MERGE STRATEGIES
-----------------
-
-resolve::
-	This can only resolve two heads (i.e. the current branch
-	and another branch you pulled from) using 3-way merge
-	algorithm.  It tries to carefully detect criss-cross
-	merge ambiguities and is considered generally safe and
-	fast.  This is the default merge strategy when pulling
-	one branch.
-
-recursive::
-	This can only resolve two heads using 3-way merge
-	algorithm.  When there are more than one common
-	ancestors that can be used for 3-way merge, it creates a
-	merged tree of the common ancestores and uses that as
-	the reference tree for the 3-way merge.  This has been
-	reported to result in fewer merge conflicts without
-	causing mis-merges by tests done on actual merge commits
-	taken from Linux 2.6 kernel development history.
-	Additionally this can detect and handle merges involving
-	renames.
-
-octopus::
-	This resolves more than two-head case, but refuses to do
-	complex merge that needs manual resolution.  It is
-	primarily meant to be used for bundling topic branch
-	heads together.  This is the default merge strategy when
-	pulling more than one branch.
-
-ours::
-	This resolves any number of heads, but the result of the
-	merge is always the current branch head.  It is meant to
-	be used to supersede old development history of side
-	branches.
+include::urls.txt[]
 
+include::merge-strategies.txt[]
 
 EXAMPLES
 --------
@@ -106,7 +70,7 @@ $ git fetch origin master:origin +pu:pu maint:maint
 $ git pull . origin
 ------------------------------------------------
 +
-Here, a typical `$GIT_DIR/remotes/origin` file from a
+Here, a typical `.git/remotes/origin` file from a
 `git-clone` operation is used in combination with
 command line options to `git-fetch` to first update
 multiple branches of the local repository and then
@@ -119,7 +83,7 @@ known to have already obtained and made available
 all the necessary objects.
 
 
-Pull of multiple branches from one repository using `$GIT_DIR/remotes` file::
+Pull of multiple branches from one repository using `.git/remotes` file::
 +
 ------------------------------------------------
 $ cat .git/remotes/origin
@@ -132,7 +96,7 @@ $ git checkout master
 $ git pull origin
 ------------------------------------------------
 +
-Here, a typical `$GIT_DIR/remotes/origin` file from a
+Here, a typical `.git/remotes/origin` file from a
 `git-clone` operation has been hand-modified to include
 the branch-mapping of additional remote and local
 heads directly.  A single `git-pull` operation while
@@ -141,6 +105,11 @@ merge the remote `origin` head into the current,
 local `master` branch.
 
 
+If you tried a pull which resulted in a complex conflicts and
+would want to start over, you can recover with
+gitlink:git-reset[1].
+
+
 SEE ALSO
 --------
 gitlink:git-fetch[1], gitlink:git-merge[1]