pack-objects: fix pack generation when using pack_size_limit
[git/mjg.git] / Documentation / git-pull.txt
blob31f42ea21a249abfa1ab2e220a077fee30d3d5e4
1 git-pull(1)
2 ===========
4 NAME
5 ----
6 git-pull - Fetch from and merge with another repository or a local branch
9 SYNOPSIS
10 --------
11 'git pull' <options> <repository> <refspec>...
14 DESCRIPTION
15 -----------
16 Runs 'git fetch' with the given parameters, and calls 'git merge'
17 to merge the retrieved head(s) into the current branch.
18 With `--rebase`, calls 'git rebase' instead of 'git merge'.
20 Note that you can use `.` (current directory) as the
21 <repository> to pull from the local repository -- this is useful
22 when merging local branches into the current branch.
24 Also note that options meant for 'git pull' itself and underlying
25 'git merge' must be given before the options meant for 'git fetch'.
27 *Warning*: Running 'git pull' (actually, the underlying 'git merge')
28 with uncommitted changes is discouraged: while possible, it leaves you
29 in a state that is hard to back out of in the case of a conflict.
31 OPTIONS
32 -------
34 Options related to merging
35 ~~~~~~~~~~~~~~~~~~~~~~~~~~
37 include::merge-options.txt[]
39 :git-pull: 1
41 --rebase::
42         Instead of a merge, perform a rebase after fetching.  If
43         there is a remote ref for the upstream branch, and this branch
44         was rebased since last fetched, the rebase uses that information
45         to avoid rebasing non-local changes. To make this the default
46         for branch `<name>`, set configuration `branch.<name>.rebase`
47         to `true`.
49 [NOTE]
50 This is a potentially _dangerous_ mode of operation.
51 It rewrites history, which does not bode well when you
52 published that history already.  Do *not* use this option
53 unless you have read linkgit:git-rebase[1] carefully.
55 --no-rebase::
56         Override earlier --rebase.
58 Options related to fetching
59 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
61 include::fetch-options.txt[]
63 include::pull-fetch-param.txt[]
65 include::urls-remotes.txt[]
67 include::merge-strategies.txt[]
69 DEFAULT BEHAVIOUR
70 -----------------
72 Often people use `git pull` without giving any parameter.
73 Traditionally, this has been equivalent to saying `git pull
74 origin`.  However, when configuration `branch.<name>.remote` is
75 present while on branch `<name>`, that value is used instead of
76 `origin`.
78 In order to determine what URL to use to fetch from, the value
79 of the configuration `remote.<origin>.url` is consulted
80 and if there is not any such variable, the value on `URL: ` line
81 in `$GIT_DIR/remotes/<origin>` file is used.
83 In order to determine what remote branches to fetch (and
84 optionally store in the tracking branches) when the command is
85 run without any refspec parameters on the command line, values
86 of the configuration variable `remote.<origin>.fetch` are
87 consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
88 file is consulted and its `Pull: ` lines are used.
89 In addition to the refspec formats described in the OPTIONS
90 section, you can have a globbing refspec that looks like this:
92 ------------
93 refs/heads/*:refs/remotes/origin/*
94 ------------
96 A globbing refspec must have a non-empty RHS (i.e. must store
97 what were fetched in tracking branches), and its LHS and RHS
98 must end with `/*`.  The above specifies that all remote
99 branches are tracked using tracking branches in
100 `refs/remotes/origin/` hierarchy under the same name.
102 The rule to determine which remote branch to merge after
103 fetching is a bit involved, in order not to break backward
104 compatibility.
106 If explicit refspecs were given on the command
107 line of `git pull`, they are all merged.
109 When no refspec was given on the command line, then `git pull`
110 uses the refspec from the configuration or
111 `$GIT_DIR/remotes/<origin>`.  In such cases, the following
112 rules apply:
114 . If `branch.<name>.merge` configuration for the current
115   branch `<name>` exists, that is the name of the branch at the
116   remote site that is merged.
118 . If the refspec is a globbing one, nothing is merged.
120 . Otherwise the remote branch of the first refspec is merged.
123 EXAMPLES
124 --------
126 * Update the remote-tracking branches for the repository
127   you cloned from, then merge one of them into your
128   current branch:
130 ------------------------------------------------
131 $ git pull, git pull origin
132 ------------------------------------------------
134 Normally the branch merged in is the HEAD of the remote repository,
135 but the choice is determined by the branch.<name>.remote and
136 branch.<name>.merge options; see linkgit:git-config[1] for details.
138 * Merge into the current branch the remote branch `next`:
140 ------------------------------------------------
141 $ git pull origin next
142 ------------------------------------------------
144 This leaves a copy of `next` temporarily in FETCH_HEAD, but
145 does not update any remote-tracking branches. Using remote-tracking
146 branches, the same can be done by invoking fetch and merge:
148 ------------------------------------------------
149 $ git fetch origin
150 $ git merge origin/next
151 ------------------------------------------------
154 If you tried a pull which resulted in a complex conflicts and
155 would want to start over, you can recover with 'git reset'.
158 SEE ALSO
159 --------
160 linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1]
163 Author
164 ------
165 Written by Linus Torvalds <torvalds@osdl.org>
166 and Junio C Hamano <gitster@pobox.com>
168 Documentation
169 --------------
170 Documentation by Jon Loeliger,
171 David Greaves,
172 Junio C Hamano and the git-list <git@vger.kernel.org>.
176 Part of the linkgit:git[1] suite