diff options
Diffstat (limited to 'Documentation/git-pull.txt')
| -rw-r--r-- | Documentation/git-pull.txt | 206 |
1 files changed, 206 insertions, 0 deletions
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt new file mode 100644 index 000000000..7578623ed --- /dev/null +++ b/Documentation/git-pull.txt @@ -0,0 +1,206 @@ +git-pull(1) +=========== + +NAME +---- +git-pull - Fetch from and merge with another repository or a local branch + + +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. +With `--rebase`, calls 'git-rebase' instead of 'git-merge'. + +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. + +Also note that options meant for 'git-pull' itself and underlying +'git-merge' must be given before the options meant for 'git-fetch'. + +OPTIONS +------- +include::merge-options.txt[] + +:git-pull: 1 + +--rebase:: + Instead of a merge, perform a rebase after fetching. If + there is a remote ref for the upstream branch, and this branch + was rebased since last fetched, the rebase uses that information + to avoid rebasing non-local changes. To make this the default + for branch `<name>`, set configuration `branch.<name>.rebase` + to `true`. ++ +[NOTE] +This is a potentially _dangerous_ mode of operation. +It rewrites history, which does not bode well when you +published that history already. Do *not* use this option +unless you have read linkgit:git-rebase[1] carefully. + +--no-rebase:: + Override earlier --rebase. + +include::fetch-options.txt[] + +include::pull-fetch-param.txt[] + +include::urls-remotes.txt[] + +include::merge-strategies.txt[] + +DEFAULT BEHAVIOUR +----------------- + +Often people use `git pull` without giving any parameter. +Traditionally, this has been equivalent to saying `git pull +origin`. However, when configuration `branch.<name>.remote` is +present while on branch `<name>`, that value is used instead of +`origin`. + +In order to determine what URL to use to fetch from, the value +of the configuration `remote.<origin>.url` is consulted +and if there is not any such variable, the value on `URL: ` line +in `$GIT_DIR/remotes/<origin>` file is used. + +In order to determine what remote branches to fetch (and +optionally store in the tracking branches) when the command is +run without any refspec parameters on the command line, values +of the configuration variable `remote.<origin>.fetch` are +consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>` +file is consulted and its `Pull: ` lines are used. +In addition to the refspec formats described in the OPTIONS +section, you can have a globbing refspec that looks like this: + +------------ +refs/heads/*:refs/remotes/origin/* +------------ + +A globbing refspec must have a non-empty RHS (i.e. must store +what were fetched in tracking branches), and its LHS and RHS +must end with `/*`. The above specifies that all remote +branches are tracked using tracking branches in +`refs/remotes/origin/` hierarchy under the same name. + +The rule to determine which remote branch to merge after +fetching is a bit involved, in order not to break backward +compatibility. + +If explicit refspecs were given on the command +line of `git pull`, they are all merged. + +When no refspec was given on the command line, then `git pull` +uses the refspec from the configuration or +`$GIT_DIR/remotes/<origin>`. In such cases, the following +rules apply: + +. If `branch.<name>.merge` configuration for the current + branch `<name>` exists, that is the name of the branch at the + remote site that is merged. + +. If the refspec is a globbing one, nothing is merged. + +. Otherwise the remote branch of the first refspec is merged. + + +EXAMPLES +-------- + +* Update the remote-tracking branches for the repository + you cloned from, then merge one of them into your + current branch: ++ +------------------------------------------------ +$ git pull, git pull origin +------------------------------------------------ ++ +Normally the branch merged in is the HEAD of the remote repository, +but the choice is determined by the branch.<name>.remote and +branch.<name>.merge options; see linkgit:git-config[1] for details. + +* Merge into the current branch the remote branch `next`: ++ +------------------------------------------------ +$ git pull origin next +------------------------------------------------ ++ +This leaves a copy of `next` temporarily in FETCH_HEAD, but +does not update any remote-tracking branches. + +* Bundle local branch `fixes` and `enhancements` on top of + the current branch, making an Octopus merge: ++ +------------------------------------------------ +$ git pull . fixes enhancements +------------------------------------------------ ++ +This `git pull .` syntax is equivalent to `git merge`. + +* Merge local branch `obsolete` into the current branch, using `ours` + merge strategy: ++ +------------------------------------------------ +$ git pull -s ours . obsolete +------------------------------------------------ + +* Merge local branch `maint` into the current branch, but do not make + a commit automatically: ++ +------------------------------------------------ +$ git pull --no-commit . maint +------------------------------------------------ ++ +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: ++ +------------------------------------------------ +$ git checkout master +$ git fetch origin +pu:pu maint:tmp +$ git pull . tmp +------------------------------------------------ ++ +This updates (or creates, as necessary) branches `pu` and `tmp` in +the local repository by fetching from the branches (respectively) +`pu` and `maint` from the remote repository. ++ +The `pu` branch will be updated even if it is does not fast-forward; +the others will not be. ++ +The final command then merges the newly fetched `tmp` into master. + + +If you tried a pull which resulted in a complex conflicts and +would want to start over, you can recover with 'git-reset'. + + +SEE ALSO +-------- +linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> +and Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Jon Loeliger, +David Greaves, +Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite |