@@ -17,29 +17,31 @@ SYNOPSIS
17
17
18
18
DESCRIPTION
19
19
-----------
20
- Fetches named heads or tags from one or more other repositories,
21
- along with the objects necessary to complete them.
20
+ Fetch branches and/or tags (collectively, "refs") from one or more
21
+ other repositories, along with the objects necessary to complete their
22
+ histories. Remote-tracking branches are updated (see the description
23
+ of <refspec> below for ways to control this behavior).
22
24
23
- The ref names and their object names of fetched refs are stored
24
- in `.git/FETCH_HEAD`. This information is left for a later merge
25
- operation done by 'git merge'.
26
-
27
- By default, tags are auto-followed. This means that when fetching
28
- from a remote, any tags on the remote that point to objects that exist
29
- in the local repository are fetched. The effect is to fetch tags that
25
+ By default, any tag that points into the histories being fetched is
26
+ also fetched; the effect is to fetch tags that
30
27
point at branches that you are interested in. This default behavior
31
- can be changed by using the --tags or --no-tags options, by
32
- configuring remote.<name>.tagopt, or by using a refspec that fetches
33
- tags explicitly.
28
+ can be changed by using the --tags or --no-tags options or by
29
+ configuring remote.<name>.tagopt. By using a refspec that fetches tags
30
+ explicitly, you can fetch tags that do not point into branches you
31
+ are interested in as well.
34
32
35
- 'git fetch' can fetch from either a single named repository,
33
+ 'git fetch' can fetch from either a single named repository or URL ,
36
34
or from several repositories at once if <group> is given and
37
35
there is a remotes.<group> entry in the configuration file.
38
36
(See linkgit:git-config[1]).
39
37
40
38
When no remote is specified, by default the `origin` remote will be used,
41
39
unless there's an upstream branch configured for the current branch.
42
40
41
+ The names of refs that are fetched, together with the object names
42
+ they point at, are written to `.git/FETCH_HEAD`. This information
43
+ may be used by scripts or other git commands, such as linkgit:git-pull[1].
44
+
43
45
OPTIONS
44
46
-------
45
47
include::fetch-options.txt[]
@@ -49,6 +51,55 @@ include::pull-fetch-param.txt[]
49
51
include::urls-remotes.txt[]
50
52
51
53
54
+ CONFIGURED REMOTE-TRACKING BRANCHES[[CRTB]]
55
+ -------------------------------------------
56
+
57
+ You often interact with the same remote repository by
58
+ regularly and repeatedly fetching from it. In order to keep track
59
+ of the progress of such a remote repository, `git fetch` allows you
60
+ to configure `remote.<repository>.fetch` configuration variables.
61
+
62
+ Typically such a variable may look like this:
63
+
64
+ ------------------------------------------------
65
+ [remote "origin"]
66
+ fetch = +refs/heads/*:refs/remotes/origin/*
67
+ ------------------------------------------------
68
+
69
+ This configuration is used in two ways:
70
+
71
+ * When `git fetch` is run without specifying what branches
72
+ and/or tags to fetch on the command line, e.g. `git fetch origin`
73
+ or `git fetch`, `remote.<repository>.fetch` values are used as
74
+ the refspecs---they specify which refs to fetch and which local refs
75
+ to update. The example above will fetch
76
+ all branches that exist in the `origin` (i.e. any ref that matches
77
+ the left-hand side of the value, `refs/heads/*`) and update the
78
+ corresponding remote-tracking branches in the `refs/remotes/origin/*`
79
+ hierarchy.
80
+
81
+ * When `git fetch` is run with explicit branches and/or tags
82
+ to fetch on the command line, e.g. `git fetch origin master`, the
83
+ <refspec>s given on the command line determine what are to be
84
+ fetched (e.g. `master` in the example,
85
+ which is a short-hand for `master:`, which in turn means
86
+ "fetch the 'master' branch but I do not explicitly say what
87
+ remote-tracking branch to update with it from the command line"),
88
+ and the example command will
89
+ fetch _only_ the 'master' branch. The `remote.<repository>.fetch`
90
+ values determine which
91
+ remote-tracking branch, if any, is updated. When used in this
92
+ way, the `remote.<repository>.fetch` values do not have any
93
+ effect in deciding _what_ gets fetched (i.e. the values are not
94
+ used as refspecs when the command-line lists refspecs); they are
95
+ only used to decide _where_ the refs that are fetched are stored
96
+ by acting as a mapping.
97
+
98
+ The latter use of the `remote.<repository>.fetch` values can be
99
+ overridden by giving the `--refmap=<refspec>` parameter(s) on the
100
+ command line.
101
+
102
+
52
103
EXAMPLES
53
104
--------
54
105
@@ -76,6 +127,19 @@ the local repository by fetching from the branches (respectively)
76
127
The `pu` branch will be updated even if it is does not fast-forward,
77
128
because it is prefixed with a plus sign; `tmp` will not be.
78
129
130
+ * Peek at a remote's branch, without configuring the remote in your local
131
+ repository:
132
+ +
133
+ ------------------------------------------------
134
+ $ git fetch git://git.kernel.org/pub/scm/git/git.git maint
135
+ $ git log FETCH_HEAD
136
+ ------------------------------------------------
137
+ +
138
+ The first command fetches the `maint` branch from the repository at
139
+ `git://git.kernel.org/pub/scm/git/git.git` and the second command uses
140
+ `FETCH_HEAD` to examine the branch with linkgit:git-log[1]. The fetched
141
+ objects will eventually be removed by git's built-in housekeeping (see
142
+ linkgit:git-gc[1]).
79
143
80
144
BUGS
81
145
----
0 commit comments