1GIT-FETCH(1) Git Manual GIT-FETCH(1)
2
6 git-fetch - Download objects and refs from another repository
7
9 git-fetch <options> <repository> <refspec>...
10
12 Fetches named heads or tags from another repository, along with the
13 objects necessary to complete them.
14 The ref names and their object names of fetched refs are stored in
16 .git/FETCH_HEAD. This information is left for a later merge operation
17 done by "git merge".
18 When <refspec> stores the fetched result in tracking branches, the tags
20 that point at these branches are automatically followed. This is done
21 by first fetching from the remote using the given <refspec>s, and if
22 the repository has objects that are pointed by remote tags that it does
23 not yet have, then fetch those missing tags. If the other end has tags
24 that point at branches you are not interested in, you will not get
25 them.
26
28 -q, --quiet
29 Pass --quiet to git-fetch-pack and silence any other internally
30 used programs.
31 -v, --verbose
33 Be verbose.
34 -a, --append
36 Append ref names and object names of fetched refs to the existing
37 contents of .git/FETCH_HEAD. Without this option old data in
38 .git/FETCH_HEAD will be overwritten.
39 --upload-pack <upload-pack>
41 When given, and the repository to fetch from is handled by
42 git-fetch-pack, --exec=<upload-pack> is passed to the command to
43 specify non-default path for the command run on the other end.
44 -f, --force
46 When git-fetch is used with <rbranch>:<lbranch> refspec, it refuses
47 to update the local branch <lbranch> unless the remote branch
48 <rbranch> it fetches is a descendant of <lbranch>. This option
49 overrides that check.
50 -n, --no-tags
52 By default, git-fetch fetches tags that point at objects that are
53 downloaded from the remote repository and stores them locally. This
54 option disables this automatic tag following.
55 -t, --tags
57 Most of the tags are fetched automatically as branch heads are
58 downloaded, but tags that do not point at objects reachable from
59 the branch heads that are being tracked will not be fetched by this
60 mechanism. This flag lets all tags and their associated objects be
61 downloaded.
62 -k, --keep
64 Keep downloaded pack.
65 -u, --update-head-ok
67 By default git-fetch refuses to update the head which corresponds
68 to the current branch. This flag disables the check. This is purely
69 for the internal use for git-pull to communicate with git-fetch,
70 and unless you are implementing your own Porcelain you are not
71 supposed to use it.
72 --depth=<depth>
74 Deepen the history of a shallow repository created by git clone
75 with --depth=<depth> option (see git-clone(1)) by the specified
76 number of commits.
77 <repository>
79 The "remote" repository that is the source of a fetch or pull
80 operation. See the section GIT URLS below.
81 <refspec>
83 The canonical format of a <refspec> parameter is ?<src>:<dst>; that
84 is, an optional plus , followed by the source ref, followed by a
85 colon :, followed by the destination ref.
86 The remote ref that matches <src> is fetched, and if <dst> is not
88 empty string, the local ref that matches it is fast forwarded using
89 <src>. Again, if the optional plus + is used, the local ref is
90 updated even if it does not result in a fast forward update.
91 Note
93 If the remote branch from which you want to pull is modified in
94 non-linear ways such as being rewound and rebased frequently, then
95 a pull will attempt a merge with an older version of itself, likely
96 conflict, and fail. It is under these conditions that you would
97 want to use the + sign to indicate non-fast-forward updates will be
98 needed. There is currently no easy way to determine or declare that
99 a branch will be made available in a repository with this behavior;
100 the pulling user simply must know this is the expected usage
101 pattern for a branch.
102 Note
105 You never do your own development on branches that appear on the
106 right hand side of a <refspec> colon on Pull: lines; they are to be
107 updated by git-fetch. If you intend to do development derived from
108 a remote branch B, have a Pull: line to track it (i.e. Pull:
109 B:remote-B), and have a separate branch my-B to do your development
110 on top of it. The latter is created by git branch my-B remote-B (or
111 its equivalent git checkout -b my-B remote-B). Run git fetch to
112 keep track of the progress of the remote side, and when you see
113 something new on the remote branch, merge it into your development
114 branch with git pull . remote-B, while you are on my-B branch.
115 Note
118 There is a difference between listing multiple <refspec> directly
119 on git-pull command line and having multiple Pull: <refspec> lines
120 for a <repository> and running git-pull command without any
121 explicit <refspec> parameters. <refspec> listed explicitly on the
122 command line are always merged into the current branch after
123 fetching. In other words, if you list more than one remote refs,
124 you would be making an Octopus. While git-pull run without any
125 explicit <refspec> parameter takes default <refspec>s from Pull:
126 lines, it merges only the first <refspec> found into the current
127 branch, after fetching all the remote refs. This is because making
128 an Octopus from remote refs is rarely done, while keeping track of
129 multiple remote heads in one-go by fetching more than one is often
130 useful.
131 Some short-cut notations are also supported.
134 · tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it
137 requests fetching everything up to the given tag.
138 · A parameter <ref> without a colon is equivalent to <ref>: when
140 pulling/fetching, so it merges <ref> into the current branch
141 without storing the remote branch anywhere locally
142
144 One of the following notations can be used to name the remote
145 repository:
146 · rsync://host.xz/path/to/repo.git/
149 · http://host.xz/path/to/repo.git/
151 · https://host.xz/path/to/repo.git/
153 · git://host.xz/path/to/repo.git/
155 · git://host.xz/~user/path/to/repo.git/
157 · ssh://[user@]host.xz[:port]/path/to/repo.git/
159 · ssh://[user@]host.xz/path/to/repo.git/
161 · ssh://[user@]host.xz/~user/path/to/repo.git/
163 · ssh://[user@]host.xz/~/path/to/repo.git
165 SSH is the default transport protocol over the network. You can
166 optionally specify which user to log-in as, and an alternate, scp-like
167 syntax is also supported. Both syntaxes support username expansion, as
168 does the native git protocol, but only the former supports port
169 specification. The following three are identical to the last three
170 above, respectively:
171 · [user@]host.xz:/path/to/repo.git/
174 · [user@]host.xz:~user/path/to/repo.git/
176 · [user@]host.xz:path/to/repo.git
178 To sync with a local directory, you can use:
179 · /path/to/repo.git/
182 · file:///path/to/repo.git/
184 They are mostly equivalent, except when cloning. See git-clone(1) for
185 details.
186
188 In addition to the above, as a short-hand, the name of a file in
189 $GIT_DIR/remotes directory can be given; the named file should be in
190 the following format:
191 URL: one of the above URL format
195 Push: <refspec>
196 Pull: <refspec>
197 Then such a short-hand is specified in place of <repository> without
200 <refspec> parameters on the command line, <refspec> specified on Push:
201 lines or Pull: lines are used for git-push and git-fetch/git-pull,
202 respectively. Multiple Push: and Pull: lines may be specified for
203 additional branch mappings.
204 Or, equivalently, in the $GIT_DIR/config (note the use of fetch instead
206 of Pull:):
207 [remote "<remote>"]
211 url = <url>
212 push = <refspec>
213 fetch = <refspec>
214 The name of a file in $GIT_DIR/branches directory can be specified as
217 an older notation short-hand; the named file should contain a single
218 line, a URL in one of the above formats, optionally followed by a hash
219 # and the name of remote head (URL fragment notation).
220 $GIT_DIR/branches/<remote> file that stores a <url> without the
221 fragment is equivalent to have this in the corresponding file in the
222 $GIT_DIR/remotes/ directory.
223 URL: <url>
227 Pull: refs/heads/master:<remote>
228 while having <url>#<head> is equivalent to
231 URL: <url>
235 Pull: refs/heads/<head>:<remote>
236
239 git-pull(1)
240
242 Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
243 <junkio@cox.net>
244
246 Documentation by David Greaves, Junio C Hamano and the git-list
247 <git@vger.kernel.org>.
248
250 Part of the git(7) suite
251Git 1.5.3.3 10/09/2007 GIT-FETCH(1)