-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathgit-fetch.txt
159 lines (130 loc) · 5.64 KB
/
git-fetch.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
git-fetch(1)
============
NAME
----
git-fetch - Download objects and refs from another repository
SYNOPSIS
--------
[verse]
'git fetch' [<options>] [<repository> [<refspec>...]]
'git fetch' [<options>] <group>
'git fetch' --multiple [<options>] [(<repository> | <group>)...]
'git fetch' --all [<options>]
DESCRIPTION
-----------
Fetch branches and/or tags (collectively, "refs") from one or more
other repositories, along with the objects necessary to complete their
histories. Remote-tracking branches are updated (see the description
of <refspec> below for ways to control this behavior).
By default, any tag that points into the histories being fetched is
also fetched; the effect is to fetch tags that
point at branches that you are interested in. This default behavior
can be changed by using the --tags or --no-tags options or by
configuring remote.<name>.tagOpt. By using a refspec that fetches tags
explicitly, you can fetch tags that do not point into branches you
are interested in as well.
'git fetch' can fetch from either a single named repository or URL,
or from several repositories at once if <group> is given and
there is a remotes.<group> entry in the configuration file.
(See linkgit:git-config[1]).
When no remote is specified, by default the `origin` remote will be used,
unless there's an upstream branch configured for the current branch.
The names of refs that are fetched, together with the object names
they point at, are written to `.git/FETCH_HEAD`. This information
may be used by scripts or other git commands, such as linkgit:git-pull[1].
OPTIONS
-------
include::fetch-options.txt[]
include::pull-fetch-param.txt[]
include::urls-remotes.txt[]
CONFIGURED REMOTE-TRACKING BRANCHES[[CRTB]]
-------------------------------------------
You often interact with the same remote repository by
regularly and repeatedly fetching from it. In order to keep track
of the progress of such a remote repository, `git fetch` allows you
to configure `remote.<repository>.fetch` configuration variables.
Typically such a variable may look like this:
------------------------------------------------
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
------------------------------------------------
This configuration is used in two ways:
* When `git fetch` is run without specifying what branches
and/or tags to fetch on the command line, e.g. `git fetch origin`
or `git fetch`, `remote.<repository>.fetch` values are used as
the refspecs--they specify which refs to fetch and which local refs
to update. The example above will fetch
all branches that exist in the `origin` (i.e. any ref that matches
the left-hand side of the value, `refs/heads/*`) and update the
corresponding remote-tracking branches in the `refs/remotes/origin/*`
hierarchy.
* When `git fetch` is run with explicit branches and/or tags
to fetch on the command line, e.g. `git fetch origin master`, the
<refspec>s given on the command line determine what are to be
fetched (e.g. `master` in the example,
which is a short-hand for `master:`, which in turn means
"fetch the 'master' branch but I do not explicitly say what
remote-tracking branch to update with it from the command line"),
and the example command will
fetch _only_ the 'master' branch. The `remote.<repository>.fetch`
values determine which
remote-tracking branch, if any, is updated. When used in this
way, the `remote.<repository>.fetch` values do not have any
effect in deciding _what_ gets fetched (i.e. the values are not
used as refspecs when the command-line lists refspecs); they are
only used to decide _where_ the refs that are fetched are stored
by acting as a mapping.
The latter use of the `remote.<repository>.fetch` values can be
overridden by giving the `--refmap=<refspec>` parameter(s) on the
command line.
EXAMPLES
--------
* Update the remote-tracking branches:
+
------------------------------------------------
$ git fetch origin
------------------------------------------------
+
The above command copies all branches from the remote refs/heads/
namespace and stores them to the local refs/remotes/origin/ namespace,
unless the branch.<name>.fetch option is used to specify a non-default
refspec.
* Using refspecs explicitly:
+
------------------------------------------------
$ git fetch origin +pu:pu maint: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,
because it is prefixed with a plus sign; `tmp` will not be.
* Peek at a remote's branch, without configuring the remote in your local
repository:
+
------------------------------------------------
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
$ git log FETCH_HEAD
------------------------------------------------
+
The first command fetches the `maint` branch from the repository at
`git://git.kernel.org/pub/scm/git/git.git` and the second command uses
`FETCH_HEAD` to examine the branch with linkgit:git-log[1]. The fetched
objects will eventually be removed by git's built-in housekeeping (see
linkgit:git-gc[1]).
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
--------
linkgit:git-pull[1]
GIT
---
Part of the linkgit:git[1] suite