1
0
mirror of https://github.com/git/git.git synced 2024-10-22 12:28:32 +02:00
git/Documentation/git-fetch.txt
Junio C Hamano 532845604d fetch doc: update introductory part for clarity
- "Branches" is a more common way to say "heads" in these days.

 - Remote-tracking branches are used a lot more these days and it is
   worth mentioning that it is one of the primary side effects of
   the command to update them.

 - Avoid "X. That means Y."  If Y is easier to understand to
   readers, just say that upfront.

 - Use of explicit refspec to fetch tags does not have much to do
   with turning "auto following" on or off.  It is a way to fetch
   tags that otherwise would not be fetched by auto-following.

Helped-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-30 11:04:37 -07:00

98 lines
2.9 KiB
Plaintext

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.
The names of refs that are fetched, together with the object names
they point at, are written to `.git/FETCH_HEAD`. This information
can be used to learn what was fetched. In addition, the remote-tracking
branches are updated (see description on <refspec> below for details).
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 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.
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.
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