line
representing the status of a single ref. Each line is of the form:

-------------------------------
 <flag> <summary> <from> -> <to> [<reason>]
-------------------------------

When using `--porcelain`, the output format is intended to be
machine-parseable. In contrast to the human-readable output formats it
thus prints to standard output instead of standard error. Each line is
of the form:

-------------------------------
<flag> <old-object-id> <new-object-id> <local-reference>
-------------------------------

The status of up-to-date refs is shown only if the --verbose option is
used.

In compact output mode, specified with configuration variable
fetch.output, if either entire `<from>` or `<to>` is found in the
other string, it will be substituted with `*` in the other string. For
example, `master -> origin/master` becomes `master -> origin/*`.

flag::
	A single character indicating the status of the ref:
(space);; for a successfully fetched fast-forward;
`+`;; for a successful forced update;
`-`;; for a successfully pruned ref;
`t`;; for a successful tag update;
`*`;; for a successfully fetched new ref;
`!`;; for a ref that was rejected or failed to update; and
`=`;; for a ref that was up to date and did not need fetching.

summary::
	For a successfully fetched ref, the summary shows the old and new
	values of the ref in a form suitable for using as an argument to
	`git log` (this is `<old>..<new>` in most cases, and
	`<old>...<new>` for forced non-fast-forward updates).

from::
	The name of the remote ref being fetched from, minus its
	`refs/<type>/` prefix. In the case of deletion, the name of
	the remote ref is "(none)".

to::
	The name of the local ref being updated, minus its
	`refs/<type>/` prefix.

reason::
	A human-readable explanation. In the case of successfully fetched
	refs, no explanation is needed. For a failed ref, the reason for
	failure is described.

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 `remote.<repository>.fetch` option is used to specify a
non-default refspec.

* Using refspecs explicitly:
+
------------------------------------------------
$ git fetch origin +seen:seen maint:tmp
------------------------------------------------
+
This updates (or creates, as necessary) branches `seen` and `tmp` in
the local repository by fetching from the branches (respectively)
`seen` and `maint` from the remote repository.
+
The `seen` branch will be updated even if it 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]).

include::transfer-data-leaks.adoc[]

CONFIGURATION
-------------

include::includes/cmd-config-section-all.adoc[]

include::config/fetch.adoc[]

BUGS
----
Using --recurse-submodules can only fetch new commits in submodules that are
present locally e.g. in `$GIT_DIR/modules/`. If the upstream adds a new
submodule, that submodule cannot be fetched until it is cloned e.g. by `git
submodule update`. 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