diff options
Diffstat (limited to 'Documentation/git-pull.txt')
| -rw-r--r-- | Documentation/git-pull.txt | 136 |
1 files changed, 126 insertions, 10 deletions
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index cef4c0ae38..ec10a2f409 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -8,18 +8,15 @@ git-pull - Pull and merge from another repository. SYNOPSIS -------- -'git-pull' <repository> <refspec>... +'git-pull' <options> <repository> <refspec>... DESCRIPTION ----------- -Runs 'git-fetch' with the given parameters. +Runs `git-fetch` with the given parameters, and calls `git-merge` +to merge the retrieved head(s) into the current branch. -When only one ref is downloaded, runs 'git resolve' to merge it -into the local HEAD. Otherwise uses 'git octopus' to merge them -into the local HEAD. - -Note that you can use '.' (current directory) as the +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. @@ -29,8 +26,125 @@ 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. + 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 ------ @@ -39,7 +153,9 @@ and Junio C Hamano <junkio@cox.net> Documentation -------------- -Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. +Documentation by Jon Loeliger, +David Greaves, +Junio C Hamano and the git-list <git@vger.kernel.org>. GIT --- |