am doc: add a pointer to relevant hooks
[gitweb.git] / Documentation / git-pull.txt
index 638456b68c1353aae3c877d62fdb115d1535d0a4..200eb22260069af7a9e2e248f0794a73e2cf4a9f 100644 (file)
@@ -3,7 +3,7 @@ git-pull(1)
 
 NAME
 ----
-git-pull - Fetch from and merge with another repository or a local branch
+git-pull - Fetch from and integrate with another repository or a local branch
 
 
 SYNOPSIS
@@ -42,6 +42,8 @@ Assume the following history exists and the current branch is
          A---B---C master on origin
         /
     D---E---F---G master
+       ^
+       origin/master in your repository
 ------------
 
 Then "`git pull`" will fetch and replay the changes from the remote
@@ -51,7 +53,7 @@ result in a new commit along with the names of the two parent commits
 and a log message from the user describing the changes.
 
 ------------
-         A---B---C remotes/origin/master
+         A---B---C origin/master
         /         \
     D---E---F---G---H master
 ------------
@@ -59,8 +61,8 @@ and a log message from the user describing the changes.
 See linkgit:git-merge[1] for details, including how conflicts
 are presented and handled.
 
-In git 1.7.0 or later, to cancel a conflicting merge, use
-`git reset --merge`.  *Warning*: In older versions of git, running 'git pull'
+In Git 1.7.0 or later, to cancel a conflicting merge, use
+`git reset --merge`.  *Warning*: In older versions of Git, running 'git pull'
 with uncommitted changes is discouraged: while possible, it leaves you
 in a state that may be hard to back out of in the case of a conflict.
 
@@ -89,7 +91,7 @@ must be given before the options meant for 'git fetch'.
        This option controls if new commits of all populated submodules should
        be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
        That might be necessary to get the data needed for merging submodule
-       commits, a feature git learned in 1.7.3. Notice that the result of a
+       commits, a feature Git learned in 1.7.3. Notice that the result of a
        merge will not be checked out in the submodule, "git submodule update"
        has to be called afterwards to bring the work tree up to date with the
        merge result.
@@ -97,17 +99,23 @@ must be given before the options meant for 'git fetch'.
 Options related to merging
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-include::merge-options.txt[]
-
 :git-pull: 1
 
+include::merge-options.txt[]
+
 -r::
---rebase::
-       Rebase the current branch on top of the upstream branch after
-       fetching.  If there is a remote-tracking branch corresponding to
-       the upstream branch and the upstream branch was rebased since last
-       fetched, the rebase uses that information to avoid rebasing
-       non-local changes.
+--rebase[=false|true|preserve]::
+       When true, rebase the current branch on top of the upstream
+       branch after fetching. If there is a remote-tracking branch
+       corresponding to the upstream branch and the upstream branch
+       was rebased since last fetched, the rebase uses that information
+       to avoid rebasing non-local changes.
++
+When preserve, also rebase the current branch on top of the upstream
+branch, but pass `--preserve-merges` along to `git rebase` so that
+locally created merge commits will not be flattened.
++
+When false, merge the current branch into the upstream branch.
 +
 See `pull.rebase`, `branch.<name>.rebase` and `branch.autosetuprebase` in
 linkgit:git-config[1] if you want to make `git pull` always use
@@ -228,7 +236,7 @@ Using --recurse-submodules can only fetch new commits in already checked
 out submodules right now. When e.g. upstream added a new submodule in the
 just fetched commits of the superproject the submodule itself can not be
 fetched, making it impossible to check out that submodule later without
-having to do a fetch again. This is expected to be fixed in a future git
+having to do a fetch again. This is expected to be fixed in a future Git
 version.
 
 SEE ALSO