48bb914ed6
The point of these sections is generally to:
1. Give credit where it is due.
2. Give the reader an idea of where to ask questions or
file bug reports.
But they don't do a good job of either case. For (1), they
are out of date and incomplete. A much more accurate answer
can be gotten through shortlog or blame. For (2), the
correct contact point is generally git@vger, and even if you
wanted to cc the contact point, the out-of-date and
incomplete fields mean you're likely sending to somebody
useless.
So let's drop the fields entirely from all manpages except
git(1) itself. We already point people to the mailing list
for bug reports there, and we can update the Authors section
to give credit to the major contributors and point to
shortlog and blame for more information.
Each page has a "This is part of git" footer, so people can
follow that to the main git manpage.
86 lines
2.3 KiB
Plaintext
86 lines
2.3 KiB
Plaintext
git-fetch(1)
|
|
============
|
|
|
|
NAME
|
|
----
|
|
git-fetch - Download objects and refs from another repository
|
|
|
|
|
|
SYNOPSIS
|
|
--------
|
|
'git fetch' [<options>] [<repository> [<refspec>...]]
|
|
|
|
'git fetch' [<options>] <group>
|
|
|
|
'git fetch' --multiple [<options>] [(<repository> | <group>)...]
|
|
|
|
'git fetch' --all [<options>]
|
|
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
Fetches named heads or tags from one or more other repositories,
|
|
along with the objects necessary to complete them.
|
|
|
|
The ref names and their object names of fetched refs are stored
|
|
in `.git/FETCH_HEAD`. This information is left for a later merge
|
|
operation done by 'git merge'.
|
|
|
|
When <refspec> stores the fetched result in remote-tracking branches,
|
|
the tags that point at these branches are automatically
|
|
followed. This is done by first fetching from the remote using
|
|
the given <refspec>s, and if the repository has objects that are
|
|
pointed by remote tags that it does not yet have, then fetch
|
|
those missing tags. If the other end has tags that point at
|
|
branches you are not interested in, you will not get them.
|
|
|
|
'git fetch' can fetch from either a single named repository, or
|
|
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]).
|
|
|
|
OPTIONS
|
|
-------
|
|
include::fetch-options.txt[]
|
|
|
|
include::pull-fetch-param.txt[]
|
|
|
|
include::urls-remotes.txt[]
|
|
|
|
|
|
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.
|
|
|
|
|
|
SEE ALSO
|
|
--------
|
|
linkgit:git-pull[1]
|
|
|
|
GIT
|
|
---
|
|
Part of the linkgit:git[1] suite
|