diff options
Diffstat (limited to 'Documentation/git-pull.txt')
| -rw-r--r-- | Documentation/git-pull.txt | 218 |
1 files changed, 147 insertions, 71 deletions
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index 94478ed94d..93c72a29ce 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -3,33 +3,137 @@ 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 -------- -'git-pull' <options> <repository> <refspec>... +[verse] +'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. +Incorporates changes from a remote repository into the current +branch. In its default mode, `git pull` is shorthand for +`git fetch` followed by `git merge FETCH_HEAD`. +More precisely, 'git pull' runs 'git fetch' with the given +parameters and calls 'git merge' to merge the retrieved branch +heads into the current branch. +With `--rebase`, it runs 'git rebase' instead of 'git merge'. + +<repository> should be the name of a remote repository as +passed to linkgit:git-fetch[1]. <refspec> can name an +arbitrary remote ref (for example, the name of a tag) or even +a collection of refs with corresponding remote-tracking branches +(e.g., refs/heads/{asterisk}:refs/remotes/origin/{asterisk}), +but usually it is the name of a branch in the remote repository. + +Default values for <repository> and <branch> are read from the +"remote" and "merge" configuration for the current branch +as set by linkgit:git-branch[1] `--track`. + +Assume the following history exists and the current branch is +"`master`": + +------------ + 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 +`master` branch since it diverged from the local `master` (i.e., `E`) +until its current commit (`C`) on top of `master` and record the +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 origin/master + / \ + D---E---F---G---H master +------------ + +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' +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. + +If any of the remote changes overlap with local uncommitted changes, +the merge will be automatically cancelled and the work tree untouched. +It is generally best to get any local changes in working order before +pulling or stash them away with linkgit:git-stash[1]. OPTIONS ------- + +-q:: +--quiet:: + This is passed to both underlying git-fetch to squelch reporting of + during transfer, and underlying git-merge to squelch output during + merging. + +-v:: +--verbose:: + Pass --verbose to git-fetch and git-merge. + +--[no-]recurse-submodules[=yes|on-demand|no]:: + 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 + 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. + +Options related to merging +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:git-pull: 1 + include::merge-options.txt[] +-r:: +--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 set to preserve, rebase with the `--preserve-merges` option passed +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 +`--rebase` instead of merging. ++ +[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. + +Options related to fetching +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + include::fetch-options.txt[] include::pull-fetch-param.txt[] -include::urls.txt[] +include::urls-remotes.txt[] include::merge-strategies.txt[] @@ -48,7 +152,7 @@ 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 +optionally store in the remote-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>` @@ -61,9 +165,9 @@ 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 +what were fetched in remote-tracking branches), and its LHS and RHS must end with `/*`. The above specifies that all remote -branches are tracked using tracking branches in +branches are tracked using remote-tracking branches in `refs/remotes/origin/` hierarchy under the same name. The rule to determine which remote branch to merge after @@ -90,79 +194,51 @@ rules apply: EXAMPLES -------- -git pull, git pull origin:: - Update the remote-tracking branches for the repository - you cloned from, then merge one of them into your - current branch. 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 gitlink:git-config[1] - for details. - -git pull origin next:: - Merge into the current branch the remote branch `next`; - leaves a copy of `next` temporarily in FETCH_HEAD, but - does not update any remote-tracking branches. - -git pull . fixes enhancements:: - Bundle local branch `fixes` and `enhancements` on top of - the current branch, making an Octopus merge. This `git pull .` - syntax is equivalent to `git merge`. - -git pull -s ours . obsolete:: - Merge local branch `obsolete` into the current branch, - using `ours` merge strategy. - -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. +* 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 +------------------------------------------------ + -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. +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. -Command line pull of multiple branches from one repository:: +* Merge into the current branch the remote branch `next`: + ------------------------------------------------ -$ git checkout master -$ git fetch origin +pu:pu maint:tmp -$ git pull . tmp +$ git pull origin next ------------------------------------------------ + -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. +This leaves a copy of `next` temporarily in FETCH_HEAD, but +does not update any remote-tracking branches. Using remote-tracking +branches, the same can be done by invoking fetch and merge: + -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. +------------------------------------------------ +$ git fetch origin +$ git merge origin/next +------------------------------------------------ -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]. +If you tried a pull which resulted in complex conflicts and +would want to start over, you can recover with 'git reset'. +BUGS +---- +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 +version. + SEE ALSO -------- -gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-config[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>. +linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1] GIT --- -Part of the gitlink:git[7] suite - +Part of the linkgit:git[1] suite |