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