@@ -17,29 +17,31 @@ SYNOPSIS
1717
1818DESCRIPTION
1919-----------
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).
2224
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
3027point 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.
3432
35- 'git fetch' can fetch from either a single named repository,
33+ 'git fetch' can fetch from either a single named repository or URL ,
3634or from several repositories at once if <group> is given and
3735there is a remotes.<group> entry in the configuration file.
3836(See linkgit:git-config[1]).
3937
4038When no remote is specified, by default the `origin` remote will be used,
4139unless there's an upstream branch configured for the current branch.
4240
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+
4345OPTIONS
4446-------
4547include::fetch-options.txt[]
@@ -49,6 +51,55 @@ include::pull-fetch-param.txt[]
4951include::urls-remotes.txt[]
5052
5153
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+
52103EXAMPLES
53104--------
54105
@@ -76,6 +127,19 @@ the local repository by fetching from the branches (respectively)
76127The `pu` branch will be updated even if it is does not fast-forward,
77128because it is prefixed with a plus sign; `tmp` will not be.
78129
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]).
79143
80144BUGS
81145----
0 commit comments