|
|
|
git-pull(1)
|
|
|
|
===========
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
|
|
|
git-pull - Pull and merge from another repository.
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
|
|
|
'git-pull' <options> <repository> <refspec>...
|
|
|
|
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
Runs `git-fetch` with the given parameters, and calls `git-merge`
|
|
|
|
to merge the retrieved head(s) into the current branch.
|
|
|
|
|
|
|
|
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::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.
|
|
|
|
|
|
|
|
|
|
|
|
EXAMPLES
|
|
|
|
--------
|
|
|
|
|
|
|
|
git pull, git pull origin::
|
|
|
|
Fetch the default head from the repository you cloned
|
|
|
|
from and merge it into your current branch.
|
|
|
|
|
|
|
|
git pull -s ours . obsolete::
|
|
|
|
Merge local branch `obsolete` into the current branch,
|
|
|
|
using `ours` merge strategy.
|
|
|
|
|
|
|
|
git pull . fixes enhancements::
|
|
|
|
Bundle local branch `fixes` and `enhancements` on top of
|
|
|
|
the current branch, making an Octopus merge.
|
|
|
|
|
|
|
|
git pull --no-commit . maint::
|
|
|
|
Merge local branch `maint` into the current branch, but
|
|
|
|
do not make a commit automatically. This can be used
|
|
|
|
when you want to include further changes to the merge,
|
|
|
|
or want to write your own merge commit message.
|
|
|
|
+
|
|
|
|
You should refrain from abusing this option to sneak substantial
|
|
|
|
changes into a merge commit. Small fixups like bumping
|
|
|
|
release/version name would be acceptable.
|
|
|
|
|
|
|
|
Command line pull of multiple branches from one repository::
|
|
|
|
+
|
|
|
|
------------------------------------------------
|
|
|
|
$ cat .git/remotes/origin
|
|
|
|
URL: git://git.kernel.org/pub/scm/git/git.git
|
|
|
|
Pull: master:origin
|
|
|
|
|
|
|
|
$ git checkout master
|
|
|
|
$ git fetch origin master:origin +pu:pu maint:maint
|
|
|
|
$ git pull . origin
|
|
|
|
------------------------------------------------
|
|
|
|
+
|
|
|
|
Here, a typical `$GIT_DIR/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
|
|
|
|
to merge the remote `origin` branch into the local
|
|
|
|
`master` branch. The local `pu` branch is updated
|
|
|
|
even if it does not result in a fast forward update.
|
|
|
|
Here, the pull can obtain its objects from the local
|
|
|
|
repository using `.`, as the previous `git-fetch` is
|
|
|
|
known to have already obtained and made available
|
|
|
|
all the necessary objects.
|
|
|
|
|
|
|
|
|
|
|
|
Pull of multiple branches from one repository using `$GIT_DIR/remotes` file::
|
|
|
|
+
|
|
|
|
------------------------------------------------
|
|
|
|
$ cat .git/remotes/origin
|
|
|
|
URL: git://git.kernel.org/pub/scm/git/git.git
|
|
|
|
Pull: master:origin
|
|
|
|
Pull: +pu:pu
|
|
|
|
Pull: maint:maint
|
|
|
|
|
|
|
|
$ git checkout master
|
|
|
|
$ git pull origin
|
|
|
|
------------------------------------------------
|
|
|
|
+
|
|
|
|
Here, a typical `$GIT_DIR/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
|
|
|
|
in the `master` branch will fetch multiple heads and
|
|
|
|
merge the remote `origin` head into the current,
|
|
|
|
local `master` branch.
|
|
|
|
|
|
|
|
|
|
|
|
SEE ALSO
|
|
|
|
--------
|
|
|
|
gitlink:git-fetch[1], gitlink:git-merge[1]
|
|
|
|
|
|
|
|
|
|
|
|
Author
|
|
|
|
------
|
|
|
|
Written by Linus Torvalds <torvalds@osdl.org>
|
|
|
|
and Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
Documentation
|
|
|
|
--------------
|
|
|
|
Documentation by Jon Loeliger,
|
|
|
|
David Greaves,
|
|
|
|
Junio C Hamano and the git-list <git@vger.kernel.org>.
|
|
|
|
|
|
|
|
GIT
|
|
|
|
---
|
|
|
|
Part of the gitlink:git[7] suite
|
|
|
|
|